Analyse et optimisation des échanges de données...
87
Analyse et optimisation des échanges de données dans le secteur médical Pambu Benjamin Sambu Mémoire présenté sous la direction du Professeur Esteban Zimányi en vue de l’obtention du grade de Licencié en Informatique Année académique 2006–2007 MEMBRE DE L’ACADÉMIE UNIVERSITAIRE WALLONIE-BRUXELLES ET DU PÔLE UNIVERSITAIRE EUROPÉEN BRUXELLES WALLONIE FACULTÉ DES SCIENCES DÉPARTEMENT D’INFORMATIQUE
Transcript of Analyse et optimisation des échanges de données...
Analyse et optimisation des échanges de données dans le secteur médical
Pambu Benjamin Sambu
Mémoire présenté sous la direction du Professeur Esteban Zimányien vue de l’obtention du grade de Licencié en Informatique
Année académique 2006–2007
MEMBRE DE L’ACADÉMIE UNIVERSITAIRE WALLONIE-BRUXELLES ET DU PÔLE UNIVERSITAIRE EUROPÉEN BRUXELLES WALLONIE
Faculté des sciencesdépartement d’inFormatique
Remerciements
Je tiens à remercier toutes les personnes qui, de près ou de loin, m’ont soutenu dans la réalisation de ce mémoire, mon directeur de mémoire, le Professeur Esteban Zimanyi, pour ses nombreux conseils et relectures, ma famille, pour leur soutien et encouragements tout au long de mes études, Véronique et Florence pour m’avoir toujours supporté durant la rédaction de ce mémoire, Vincent Dock, Stéphane Nguyen et Olivier Caudron dont l’apport aura été remarquable, Ainsi que mon Dieu pour le souffle de vie.
A mes parents, Pierre Sambu Nzita et Albertine Vuavu Paku
Table des matières
1. Introduction 3
1.1 Objectif ....................................................................................................... 4 1.2 Importance et motivation ........................................................................ 5
2. Echanges de données dans le secteur médical en Belgique 7
2.1 Introduction............................................................................................... 7 2.2 Be–Health................................................................................................... 9 2.3 Numéro Health Personal Id Nummer (HEPI).................................... 10
2.3.1 Introduction.................................................................................. 10 2.3.2 Proposition de Création des numéros HEPIs–Rapport HEPI-GO ..................................................................................................................... 12 2.3.3 Conclusion .................................................................................... 25
2.4 The Bilingual Biclassified Belgian Terminology ou Thesaurus 3BT 27 2.4.1 Introduction.................................................................................. 27 2.4.2 Historique ................................................................................... 28 2.4.3 ICD-10 et ICPC-2......................................................................... 29 2.4.4. Systèmes terminologiques........................................................ 34 2.4.5. Composition du 3BT ................................................................. 35 2.4.6 Table de labels Cliniques ........................................................... 37 2.4.7 Conclusion ................................................................................... 38
2.5 Kind Messages for Electronic Healthcare Record – Belgian Implementation Standard (KMEHR – bis).................................................. 39
2.6 Summarized Electronic Health Record – SUMEHR.................................. 43 2.7 Réseaux médical Belge................................................................................... 45
3. Echanges de données dans le secteur médical à l’étranger 48
3.1 Introduction..................................................................................................... 48 3.2 Système centralisé........................................................................................... 48 3.3 Systèmes décentralisés ................................................................................... 50
2
4. Modélisation d’un réseau d’échanges de données dans le secteur
médical en Belgique 58
4.1 Introduction..................................................................................................... 58 4.2 Approche générale ......................................................................................... 59 4.3 Groupe Fonctionnel : GF ............................................................................... 61
4.3.1 Présentation ............................................................................................ 61 4.3.2 Mesures à prendre afin que la propriété GF soit respectée ............. 63
4.4 Serveur Central: National Health Connect Exchange (NHCX)............. 64 4.4.1 Presentation ............................................................................................ 64 4.4.2 Tables gérées par le NHCX .................................................................. 65
4.5 Authentification .............................................................................................. 67 4.6 Scénarios .......................................................................................................... 68
5. Implémentation 69
5.1 Introduction..................................................................................................... 69 5.2 Modèle Vue Contrôleur (MVC) .................................................................... 69
5.2.1 Introduction............................................................................................ 69 5.2.3 Notre implémentation........................................................................... 75
5.3 Conclusion ....................................................................................................... 79
6. Conclusion 80
7. Annexe 82
8. Bibliographie 83
3
Chapitre 1
Introduction
L’évolution des soins de santé en Belgique et dans le monde n’est plus à
démontrer, tant elle est visible et incontestable.
Ces dernières décennies, nous avons assisté à une amélioration remarquable des
soins de santé, suite, entre autre, à l’introduction et au développement des outils
informatiques dans le milieu médical.
Cela se manifeste aussi par plusieurs prouesses réalisées par la médecine grâce à
l’informatique.
Certaines sont spectaculaires (par exemple : les opérations réalisées à l’aide de
robots), d’autres sont moins spectaculaires mais non moins négligeables. Pour
exemple :
- Le stockage des fichiers médicaux grâce à l’informatique qui garantit une
meilleure conservation des documents, un gain en espace considérable, et
un accès rapide aux dossiers des patients tout en limitant l’accès qu’au
personnel de santé ayant droit ;
- Dans les échanges de données, un exemple pourrait être celui existant entre
les centres de santé et les mutuelles. En effet, il y a 20 ans, les hôpitaux et
mutuelles correspondaient par courriers postaux (courtiers). Et lorsqu’un
colis partait d’un hôpital vers une mutuelle, si le transporteur atteignait la
4
mutuelle alors que celle-ci était déjà fermée, il déposait le colis tout
simplement à la porte de la mutuelle, avec toutes les conséquences graves
que cela pouvait engendrer.
Aujourd’hui, les méthodes informatiques de courrier électronique
garantissent non seulement que le courrier arrive de manière instantanée,
mais aussi qu’il soit sécurisé et authentifié.
L’informatique a encore un grand rôle à jouer dans le secteur médical et un rôle
majeur dans ce cas précis qui est celui des échanges de données médicales.
1.1 Objectif
Il est donc question dans ce travail de fin d'année d’étudier la mise en place
et le fonctionnement optimal d’un système de partage de données commun à tous
les services de soins de santé en Belgique. Un système d'échange d’informations
qui permettra aux professionnels de santé de travailler dans de meilleures
conditions dans différentes échelles et d’améliorer considérablement la qualité des
soins donnés aux patients.
Concrètement, cela pourrait revenir à mettre en place une base de données
commune dans laquelle les différents acteurs de santé devront déposer et/ou
prendre des informations médicales concernant leurs patients dans le but de
favoriser une meilleure communication et surtout une amélioration des soins de
santé.
Ceci permettrait d’éviter, par exemple, qu'un même examen médical soit fait
plusieurs fois sur un même patient alors qu’on aurait pu se rendre compte qu’il
avait déjà été fait auparavant par un autre médecin.
Un cas concret pourrait être celui du bruxellois qui en visite à Anvers est sujet à
une crise cardiaque. On devra lui faire une série d’examens qu’il a peut être passé
quelques jours auparavant à Bruxelles.
5
Ou encore, le médecin d’Anvers pourrait prescrire un médicament contenant une
substance à laquelle le patient est allergique.
Nous voyons bien que dans notre cas, il est important que le centre de santé à
Anvers, dans lequel le patient est emmené, puisse avoir accès à des informations
concernant son dossier médical.
1.2 Importance et motivation
Nous venons de montrer, par quelques exemples, l’importance du
développement de l’informatique dans le secteur médical en ce qui concerne
l’amélioration de la qualité des soins. En effet, comme dit plus haut, l’informatique
dans le secteur médical apporte une grande aide notamment dans les prises de
décisions, dans les calculs statistiques, le stockage des données et autres.
Bon nombre de médecins qui ont décidé d’informatiser leurs services ont déclaré
être plus efficaces dans la mesure ou ils peuvent plus facilement, à partir de leurs
ordinateurs, calculer le nombre de patients présentant tels ou tels symptômes et à
telle ou telle période de l’année, et l’efficacité de tel ou tel traitement.
Le développement des échanges de données dans le secteur médical contribue
aussi à la qualité des soins, par exemple lorsqu’un nouveau cas se présente dans
un hôpital, le médecin pourra vite trouver un autre hôpital en Belgique où le
même cas s’est déjà produit et en l’occurrence voir comment il a été traité.
Comme dit précédemment, il permettra aussi que des examens déjà faits sur un
patient ne soient pas refaits systématiquement par un autre médecin qui aurait
besoin des ces résultats. Ce qui entraîne aussi une économie importante d’argent
pour les mutuelles, les patients et les centres de santé.
Il limitera fortement les erreurs de prescriptions. Pour donner quelques chiffres,
aux Etats-Unis, 50% des erreurs médicales évitables liées aux médicaments,
viennent de prescriptions incorrectes ceci équivaut à 98 000 morts par an. En
6
Grande-Bretagne, cela représente environ 400 000 erreurs médicales par an et
34000 morts. [1]
Aussi, il permettra d’avoir une information exacte et précise sur le passé médical
d’un patient. Très souvent nous n’avons que la parole du patient et même pire,
celle d’un proche du patient ; dites paroles qui souvent sont imprécises.
Avec une mise en commun des dossiers médicaux informatisés, le médecin
connaîtra le passé médical de son patient avec les termes d’un médecin.
En étendant ces échanges de données aux pharmacies, nous pourrons arriver à
faire en sorte que les ordonnances médicales soient stockées dans une base de
données à laquelle les pharmacies auront accès. Dans ce cas l’ordonnance
médicale ne serait plus qu’un simple code qui serait un mot de passe permettant
au pharmacien d’accéder à la véritable ordonnance en ligne.
Mettre en place un tel système sera énormément avantageux pour :
- les patients, qui pourront être sûr d’avoir de meilleurs soins dans la mesure
où chaque fois qu’ils auront à faire à un nouveau médecin, ce médecin
connaîtra leur passé médical avec les mots d’un autre médecin ce qui
rendra sa compréhension beaucoup plus claire;
- les hôpitaux et autres professionnel de santé, auxquels on évitera de conserver
de nombreux papiers qui trouvent de moins en moins de place en ce début
de troisième millénaire et facilitera énormément les transferts de dossiers en
temps et en argent ;
- les mutuelles, qui n’auront plus à rembourser comme c’est parfois le cas le
même traitement plusieurs fois.
9.
7
Chapitre 2
Echanges de données dans le secteur médical en
Belgique
2.1 Introduction
En Belgique, il n’existe pas de logiciel ayant l’exclusivité des échanges de
données dans le secteur médical et en matière de stockage informatique des
données médicales.
En ce qui concerne l’informatisation des centres de santé, de nombreux logiciels
existent. Et chaque centre de santé peut choisir librement lequel utiliser. On a là un
système assez libéral; Il n’y a pas d’organe pouvant décider si un logiciel est assez
bon pour être utilisé dans le secteur, cela est laissé à la seule appréciation de
l’utilisateur.
Tout ceci a entraîné qu’il y ait la création, vers la fin des années 1990, d’un nombre
important de logiciels, certains bons, d’autres contenant néanmoins une série
d’ « horreurs », comme par exemple, l’absence de notion de date, ces logiciels étant
surtout incompatibles les uns envers les autres.
Ceci rend, dans cet état, les échanges de données quasi impossibles.
Pour palier à tout cela, il a été instauré en Belgique dans ces mêmes années (1997-
1999) une structure d’homologation volontaire ou plutôt de labellisation, car il ne
s’agit pas ici d’homologuer mais plutôt de labelliser les logiciels. Cet organe sert
de gardes fous permettant de donner un minimum de sécurité à l’utilisateur. Il
8
établit un certain nombre de critères, (333 en 1999) mais beaucoup plus
aujourd’hui, tels que le codage ICPC/ICP1 qui est obligatoire, ou encore,
l’utilisation d’une base de données médicamenteuses.
Plusieurs organes y travaillent, comme EMDMI, PROREC BE, une équipe
d’informaticiens, chercheurs de différentes universités, médecins et personnel
médical.
Etant donné qu’on ne peut obliger un médecin à utiliser un logiciel labellisé, la
méthode utilisée est d’opérer plutôt par des récompenses offrant une prime de 700
euros aux médecins qui voudront bien en utiliser un.
Mais cela résout plutôt le problème du choix du logiciel de la part des médecins
plutôt que celui de l’incitation à passer à l’informatisation de leur système étant
donné que les 700 euros octroyés sont moindres par rapport au coût
d’informatisation.
Si il est relativement facile de soumettre tous les centres de santé à
l‘informatisation de leur service notamment pour la conservation des dossiers, ce
qui est déjà fait, par arrêté Royal, il est plus difficile de faire de même avec les
médecins privés qui travaillent sans depuis plusieurs dizaines d’années.
Pourtant, une participation de tout le personnel médical concerné est nécessaire
afin de s’assurer de l’exhaustivité du dossier consulté.
Pour y arriver, des séances de travail entre médecins, informaticiens et tous les
autres acteurs de ce grand projet d’échanges de données sont régulièrement
organisées.
Malgré le fait que cela soit un procédé long et bloquant, surtout en matière de
prise de décision (il est en effet difficile de contenter tout le monde à 100%), ces
réunions permettent d’entendre les avis de tous, et en particulier de ceux à qui les
logiciels sont destinés ce qui est non négligeable.
9
2.2 Be–Health
En décembre 2006, une loi crée la structure Be-Health [10]. Cette dernière
est chargée de reprendre un certain nombre de tâches liées à l’informatisation des
données de santé.
A ce jour, un bon nombre de projets ont déjà été concrétisés, ou sont en train de
l’être. Il s’agit notamment de :
- la facturation du tiers-payant pour les infirmières et groupes d’infirmières,
- accès en réseau des données d’assurabilité pour les infirmières,
- cadastre des soins de santé,
- identification pour le registre du cancer,
- feed-back électronique des organismes assureurs vers les hôpitaux des
examens pré-opératoires, etc.
Pour chaque projet-pilote, des services à valeur ajoutée sont gestionnaires des
données. Ceux-ci reçoivent de Be-Health des services de base et des sources
authentiques validées.
Be-health a aussi des projets à plus long terme, ceux-ci permettent de donner accès
à des services très concrets :
- déclaration de naissance par les personnes autorisées (médecins et
accoucheurs),
- informatisation anonymisée de registres pour des implants (pace-maker,
prothèse) et pour les anti-TNF,
- introduction électronique des demandes de reconnaissance du statut
d’handicapé.
L’optique dans laquelle se range la plupart des projets de Be-Health vise la
simplification administrative dans un domaine très spécifique.
10
L’intérêt que nous portons à la présentation de Be-Health est le fait qu’elle est la
structure étatique belge chargée du sujet qui ici nous intéresse, notamment la mise
en place d’un réseau d’échanges de données dans le secteur médical.
2.3 Numéro Health Personal Id Nummer (HEPI)
2.3.1 Introduction
Chaque fois qu’un patient est admis dans un hôpital, un dossier médical est
créé portant un numéro d’identification relatif à ce patient. Ce dit numéro est
interne à l’hôpital.
Le but recherché en voulant créer un numéro d’identification Santé Personnel, est
d’assurer le suivi du patient dans l’espace et dans le temps, à travers différentes
admissions dans différents centres de santé. Tout cela dans des contextes
d’utilisation spécifiques prédéfinis comme celui par exemple de la transmission de
message entre dossiers patients électroniques.
Les données de santé auxquelles un numéro HEPI serait attribué ne permettront
pas, en général, d’identifier directement la personne concernée.
D’où, la fonction du numéro HEPI est de pouvoir, dans un contexte légitime, relier
différentes données relatives à une même personne, tout en restant anonyme.
Le numéro HEPI n’a pas la prétention de remplacer le numéro d’identification de
la sécurité sociale (NISS) là où ce dernier est utilisé pour la gestion de données
liées à un patient dans le domaine de la sécurité sociale.
Pour que les numéros HEPIs remplissent leur rôle efficacement, ils devront
respecter sept critères :
1) Isolement des données de santé
Au vu de leurs caractères intimes et confidentiels, les données de santé
nécessitent un traitement exceptionnel et une protection de rigueur.
11
Aussi, elles doivent être indépendantes des fichiers des autres données
juridiques ou sociales concernant le même citoyen.
La manipulation des dossiers patients à l’intérieur des centres de santé,
hôpitaux et cabinets médicaux correspond à un couplage des données de
santé avec des données administratives, sociales ou comptables mais ces
correspondances ne peuvent persister lors de la transmission et la collecte de
données en dehors de ces systèmes locaux.
2) Contextes imperméables
Un numéro HEPI spécifique est attribué à un patient pour chaque contexte
d’utilisation dans lequel son usage est limité.
D’où plusieurs numéros HEPIs peuvent être attribués à un même patient
lorsqu’il est concerné par plusieurs contextes d’utilisation.
Le respect de contextes imperméables implique que dans chaque contexte
d’utilisation, les HEPIs sont uniques pour chaque patient.
3) Dépersonnalisation
Une dépersonnalisation absolue implique le fait que les numéros HEPIs ne
peuvent contenir aucune information décrivant le patient (âge, sexe, etc.) ni
être générés par des méthodes permettant d’identifier le patient ni contenir
d’informations permettant d’identifier son contexte d’utilisation.
4) Transparence
Malgré le fait que la plupart des contextes d’utilisation correspondront à des
techniques informatiques de stockage et d’échanges de données, les numéros
HEPIs doivent pouvoir être lus et recopiés par un humain.
5) Niveaux de production
On a deux types de numéros HEPIs :
12
- Des HEPIs dits principaux : qui sont générés selon une méthode
commune pour usages au niveau national.
- Des HEPIs dits supplémentaires : qui sont générés localement pour
usages plus restreints.
6) Internationalisation
Bien que gérés au niveau national, les numéros HEPIs, doivent pouvoir être
utilisés au niveau international, au moins européen.
7) Evolutivité
Pour des raisons de sécurité, les numéros HEPIs existants doivent pouvoir
être remplacés par d’autres HEPIs équivalents lorsque l’évolution
technologique le requiert.
2.3.2 Proposition de Création des numéros HEPIs–Rapport HEPI-GO
Il est fort tentant d’utiliser le numéro NISS (numéro d’identification pour la
sécurité sociale) porté par la carte SIS au vu des nombreux avantages que cela
apporterait [11].
Il faudra cependant y ajouter un ensemble de précautions légales et techniques
pour éviter le couplage des données de santé avec d’autres fichiers de données.
Mais, on s’aperçoit vite de la grande complexité et du coût de mise en œuvre de
telles précautions ajouté à cela qu’avec un seul identifiant, on n’a pas de notion de
contextes imperméables partiellement signifiants.
Cependant, l’unicité de ce numéro et sa facilité de consultation font qu’il serait le
point de départ pour la génération de la plupart des HEPIs primaires.
Un HEPI primaire pourrait être généré au départ du numéro de sécurité sociale
NISS.
HEPI primaire = f (NISS)
13
Un HEPI secondaire ne pourrait être généré qu’au départ d’un HEPI existant
(primaire ou secondaire).
HEPI secondaire = f (HEPI primaire) | f (HEPI secondaire)
Les HEPIs seraient alors créés par des intermédiaires de confiance nommés
«serveurs d’HEPIs » et répondant à des spécifications fonctionnelles et
organisationnelles communes.
Les HEPIs seraient constitués de la juxtaposition d’un code HEPI (résultat de
cryptage) et d’un code de contrôle (check-digit).
Un code HEPI serait le résultat d’une transformation cryptographique irréversible
réalisée au sein des serveurs d’HEPIs et utilisant des algorithmes publics contrôlés
par des clés de cryptage secrètes.
La relation entre un HEPI et son contexte d’utilisation n’est connue que par le
serveur d’HEPIs qui l’a créée et les utilisateurs finaux de l’HEPI.
2.3.1.1 De l’INSS à l’HEPI «primaire »
La fonction qui transforme l’input (INSS) en l’output (HEPI « primaire »), doit
respecter les exigences suivantes :
- être irréversible « one-way » ;
- ne produire aucune collision, en d’autres termes, doit être bijective ;
- respecter une contrainte de longueur ;
- avoir un espace input limité ;
- ne pouvoir être exécutée que par des personnes autorisées.
Force est de constater que rencontrer toutes ses exigences simultanément semble
être impossible.
A notre connaissance, il n’existe pas de schéma de chiffrage de clé publique
sécurisé ou de permutation irréversible d’aussi petite taille.
14
Nous pensons premièrement aux fonctions de chiffrage mais ceux-ci ne sont pas
irréversibles. Et ensuite aux solutions basées sur les techniques de hachage mais
ceux-ci ne résolvent pas le problème des collisions.
D’un point de vue purement cryptographique, une solution serait d’assouplir une
des 5 exigences.
Nous choisissons d’assouplir le caractère strict d’une fonction exempt de collision.
Ainsi nous pourrons utiliser des fonctions permettant, avec une très faible
probabilité, l’existence de collision.
Etant donné que dans notre cas actuel, il est clair que nous ne pouvant quand
même pas permettre que de deux INSS différents on ait un même HEPI, nous
remédierons à cela par une vérification explicite.
Le choix de cette démarche se justifie par le fait que le risque de collision est
tellement faible qu’il peut être arrondi à zéro et est préférable à la menace de voir
un utilisateur étranger retrouver un INSS, et par conséquent l’identité d’un
patient, à partir d’un HEPI.
2.3.1.2 Primitives cryptographiques
a) Fonctions irréversibles ou « one–way »
Lorsqu’on parle d’irréversibilité au niveau mathématique, on ne peut
s’empêcher de penser aux primitives cryptographique de Hashage et MAC.
Dans le cas où nous voudrions limiter l’exercice de la transformation qu’aux
personnes autorisées, la fonction Mac semble être mieux adaptée.
Comme dit plus haut, ces fonctions ne nous épargnent pas des collisions.
La probabilité d’avoir une collision est relative à la longueur des bits. La table
ci-dessous illustre la probabilité d’expérimenter une collision par rapport à la
longueur de l’output et du nombre des inputs.
On peut la lire de la façon suivante : si l’output de la fonction de hashage est
limitée à 13 chiffres alphanumériques, et qu’il y a actuellement 15.000.000
INSSs en circulation, alors, nous avons une probabilité de 3% d’expérimenter
une seule collision dans les HEPIs.
15
# chiffres alphanumérique (sans le checksum) dans HEPI
Espace taille (bits)
# de valeur d’output possible
# INSS en circulation
Probabilité d’avoir une seule collision
20 103 1,33675 E+31 15.000.000 0
18 93 1,03144 E+28 15.000.000 1,09 E-14
13 67 1,70582 E+20 15.000.000 6,6 E-07
10 51 3,65616 E+15 15.000.000 0,030301
20 103 1,33675 E+31 30.000.000 0
18 93 1,03144 E+28 30.000.000 4,36 E-14
13 67 1,70582 E+20 30.000.000 2,64 E-06
10 51 3,65616 E+15 30.000.000 0,115807
TAB. 2.1 - Probabilité d’expérimenter une collision par rapport à la longueur de l’output et du nombre des inputs [11].
La probabilité que sur n entier aléatoires tirés d’une distribution uniforme
discrète avec la gamme [1, d], on ait deux nombres identiques est donnée par la
formule suivante.
p(n,d)~1-exp(-n(n-1)/(2d))
Malgré que la probabilité d’expérimenter une collision soit faible, ce cas de
figure ne peut être accepté dans notre travail.
Et l’utilisation de ces primitives sans collision n’est pas possible.
b) Crypto-systèmes à clé publique
L’irréversibilité peut s’obtenir par une fonction dérivée en utilisant un
crypto-système à clé publique sans avoir à faire au problème de collision
susmentionné, lorsque la fonction donnant le HEPI est basée sur une clé
publique dans un crypto-système et que la clé privée correspondante est
détruite par la suite. Ainsi nous avons l’irréversibilité dans le sens où sans la
clé privée on ne peut partir de l’HEPI en sens inverse.
A notre connaissance, il n’existe pas de système à clé publique capable de
générer un output suffisamment petit d’une manière sécurisée.
16
c) Crypto-systèmes à clé symétrique 5
Le chiffrage symétrique nous donne de nombreux avantages dans notre cas
précis. Cette opération est bien entendu bijective pour une seule clé, par
conséquent nous éviterons les collisions possibles par l’utilisation d’une seule
clé.
Malgré cet avantage, nous avons toujours le grand désavantage du caractère
réversible étant donné que le chiffrage et le déchiffrage sont effectués à partir
d’une même clé.
En conclusion, si la transformation de l’INSS en HEPI devait se baser sur un
chiffrage symétrique, alors on pourrait aussi bien retrouver les INSSs à partir
des HEPIs, tout simplement en reversant le chiffrage.
Dans notre cas, nous sommes exemptés de collision et la transformation peut
dès lors se faire simplement par un algorithme « clean-cut » qui assure le
caractère unique des HEPIs.
Dans une alternative « one-way », retrouver les INSSs à partir des HEPIs est
mathématiquement impossible. Mais étant donné l’espace d’input qui se
restreint au nombre d’INSSs, cela peut se faire sans utiliser beaucoup de
ressources par une recherche exhaustive.
Deux approches
Nous venons de voir qu’il est très difficile de satisfaire simultanément toutes
les conditions imposées au numéro HEPI.
Pour y arriver, le projet HEPI–GO mandaté par le comité Télématique dans le
but de faire une étude de faisabilité sur la conversion des INSS aux HEPIs,
propose deux approches :
1) une solution basée sur le chiffrage symétrique sans collision mais qui ne
serait pas irréversible (non « one-way »)
2) Une solution basée sur une fonction one-way qui exige une base de
données centralisée et une clé tag afin d’être exempt de collision
17
Approche 1 : Algorithme de conversion concise
Cette approche offre une solution donnant un numéro HEPI en ayant comme
seul input l’INSS.
Dans ce cas, toutes les opérations nécessitant une clé secrète doivent s’effectuer
dans un environnement certifié sécurisé (HSM – Hardware Security Module).
Malgré le fait que l’utilisation d’un secret invariable pour générer les HEPIs
pour une durée de temps indéfinie ne soit pas recommandée en matière de
sécurité, Les contraintes assignées à l’HEPI imposent, d’une certaine manière,
l’utilisation d’un secret universel comme seule clé. Si après un laps de temps
cette clé est changée, on ne pourra garantir, même avec un schéma de chiffrage
symétrique, que des collisions n’apparaîtront pas.
La solution naturelle à ce problème serait d’introduire une clé identifiant
(KeyID) dans le HEPI.
On aurait donc :
HEPI = inssToHEPI(INSS) = {EK(INSS), KID}
Ceci créera un HEPI comme par exemple :
KKKK – HHHH – HHHH – HHHH – C
« K » étant déterminé par la « KeyID » et « H » par EK(INSS).
Ainsi, même si l’algorithme de conversion présentait des cas de collision,
lorsqu’on utiliserait différentes clés de chiffrage, les HEPIs seraient quand
même différents de par la KeyID.
Ce procédé présente tout de même un gros inconvénient, suite au fait qu’il
désobéit à l’exigence stipulant qu’un HEPI ne peut varier au fil de temps. Ce
qui implique que le choix de la clé ne doit dépendre que de l’INSS, tel que
l’INSS soit le seul paramètre input de l’algorithme.
La figure ci-dessous présente un schéma résolvant ce problème. Dans cet
algorithme, la transformation d’un INSS en HEPI s’opère en deux étapes :
1) exécuter le chiffrage avec une clé variable
18
2) utiliser un secret universel fixe
Cet algorithme permet par sa clé variable de réduire le nombre de HEPIs
généré par une même clé, sans pour autant qu’il n’y ait de fuite d’information
concernant l’INSS.
FIG. 2.1 – Algorithme de conversion concise d’INSS en HEPI : 2 étapes de conversion.
L’algorithme
- L’INSS est écrit en 64 bit, avant d’être chiffré par E1(.)
- E1(.) est un chiffreur symétrique de block de 64 bit. La clé K1 utilisé est
choisie à partir d’une liste sécurisée. A chaque unique Ki est associé un
unique KIDi de n-bit. Le choix du KIDi désigné pour le chiffrage ne dépend
que de l’INSS
- Le KID de la clé de chiffrage est apposé à l’output du chiffrage, ayant pour
résultat une valeur intermédiaire de (64+n) bits.
19
- E2(.) est une construction « Bellare–Rogaway » basé sur un chiffreur
symétrique de block de 64 bits. La clé utilisée dans ce cas est fixe, c’est le
secret universel.
- L’output de (64+n) bits résultant est alors encodé par Base32 donnant un
résultat de (64+n) / 5 caractères auquel on ajoute un « checksum ».
Conclusion
En dépit du fait d’avoir là un algorithme à clés variables, cette approche dépend
toujours d’un secret universel. La sécurité ajoutée par l’ajout d’une clé variable est
limitée par rapport à ce à quoi l’on pourrait s’attendre.
Ainsi, si la KeyID est fortement dérivée de l’INSS (par exemple, si elle varie par
rapport à l’année de l’encodage de l’INSS), alors ceci pourrait être une faiblesse
qu’un « pirate » pourrait facilement exploiter. En effet, en ayant un ensemble de
paires {INSS, HEPI} à sa disposition, un « pirate » pourrait grouper les HEPIs
générés avec la même clé (dans l’étape 2). Ceci pour l’aider dans sa tentative de
découvrir la clé universelle ; Par exemple, lorsque ces HEPIs sont décryptés avec
une clé réelle, ils contiendront la même KeyID.
En allant plus loin, avec l’éventualité qu’un « pirate » découvre la clé universelle,
il sera alors capable de retrouver la KeyID de chaque HEPI. Il pourra plus tard
découvrir la signification de chaque KeyID dans la génération des paires {INSS,
HEPI} qu’il connait.
Une façon d’éviter cette faiblesse serait alors de rendre la sélection de la Key (à
l’étape 1) imprévisible aux « pirates ».
La différence réside dans le fait qu’un nombre fixe de clés pré généré doit être
utilisé. Malgré l‘utilisation d’une clé universelle dans la seconde étape, le schéma
de sélection de la clé la rend plus difficile à briser.
20
Cela se traduit par le schéma suivant :
FIG. 2.2 – Algorithme de conversion concise d’INSS en HEPI : sélection de la clé.
Approche 2 : Table de translation, fonctions « one – way » et vérification des
collisions.
Comme dit précédemment, il n’y a pas, à notre connaissance et au moment où
ce mémoire est écrit, de solution à la fois exempte de risque de collision, aussi
infime soit elle, et respectant la contrainte de longueur et d’irréversibilité.
Ainsi, une vérification de collision en temps réel est requise lors de la création
de l’HEPI à partir de l’INSS.
Il existe un bon nombre de solutions différentes basé sur cette approche. Mais
il est tout de même important de se rendre compte que toutes ces solutions ont
en commun le principe de l’utilisation d’une table de conversion entre l’INSS et
les numéros HEPI purement aléatoire.
Ici, lorsque un HEPI doit être créé à partir d’un INSS, l’application vérifiera
dans la table si une entrée correspondante INSS – HEPI n’est pas déjà listée. Si
c’est le cas, alors le HEPI correspondant est tout simplement retourné. Sinon,
21
on se trouve en face d’un cas de première demande et un nouveau HEPI doit
être généré.
Cela se traduit par la figure suivante :
FIG. 2.3 – Algorithme de conversion con d INSS en HEPI : Table de conversion simple.
En effet, une « simple » table de conversion avec des HEPIs générés aléatoirement
offre une solution beaucoup plus efficace que ce à quoi on s’attend intuitivement.
Premièrement, il n’y a virtuellement pas de contrainte concernant le format et la
longueur des HEPIs. En plus, la conversion est strictement irréversible face à une
« crypto – attaque ». Pour une « infrastructure – attaque », une protection
équivalente à celle vue dans la première approche est offerte. Etant donné que les
recherches dans la base de données ne concernent que les INSSs, les HEPIs
peuvent être stockés dans une forme cryptée.
La sécurité repose alors sur une gestion des clés, laquelle peut être manipulée par
un HSM, offrant ainsi le plus haut niveau de sécurité possible.
22
Pour un « pirate » bien informé (une personne de confiance venue de l’intérieur
du système mais ayant des intentions malhonnêtes), il est aisé de renverser la
transformation de l’INSS à l’HEPI.
Pour palier à cela, une amélioration remplace la génération aléatoire des HEPIs
par une fonction « one–way ». A chaque INSS est associée une clé secrète (au
travers d’un KeyID). Cette clé est utilisée dans une fonction avec l’INSS pour
générer l’HEPI. Chaque fois qu’un nouvel INSS est rencontré, une clé candidate
est sélectionnée, et le HEPI correspondant est calculé. Si nous avons un cas de
collision d’HEPIs, alors une nouvelle clé candidate est sélectionnée.
Cette opération est répétée tant qu’il y aura collision.
Ensuite, la base de donnée INSS–KeyID et le HEPI sont mises jour.
Ici, la base de données INSS-KeyID peut être déléguée à une partie différente
(contexte différent de sécurité) que le reste du calcul. De cette façon, l'information
pour faire le lien entre INSS et HEPI est distribuée (entravant la génération de
dictionnaire).
Ainsi, un « pirate bien informé » devra investir d’énormes efforts afin de créer un
dictionnaire qui permettra de renverser les HEPIs.
Dans la solution précédente (table de conversion), un tel dictionnaire est en soit
présent.
Ceci se traduit par le schéma suivant :
23
FIG. 2.4 – Algorithme de conversion d’INSS en HEPI : Transformation « one-way».
Pré-évaluation de la vérification des Collisions
Pour repérer les éventuelles collisions, il est nécessaire de stocker tous les INSSs et
HEPIs rencontrés. Ceci ne pause aucun problème technique n’exigeant pas un
grand volume de stockage.
Etant donné l’espace limité d’input que nous fournit l’INSS, on peut penser à
exploiter cet avantage pour la vérification des collisions. Ceci signifie que pour
chaque nouvelle clé utilisée dans une transformation one–way (telle que HMAC),
l’espace complet d’input est contrôlé pour d’éventuelles collisions (recherche
exhaustive). Si aucune collision n’est détectée, alors la clé peut être utilisée. Malgré
le fait que cela soit techniquement faisable de suivre cette approche pour l’espace
INSS complète, cette solution n’est pas considérée comme pratique.
Mais il sera tout de même intéressant d’incorporer cette technique dans
l’algorithme de la figure 4.2.4, en remplaçant la première étape par une fonction
one–way de chiffrage symétrique avec une vérification pour les collisions. Ceci
24
nous donne comme résultat la figure ci-dessous. En réduisant l’espace input de la
fonction one–way, la détection de collision est rendue pratiquement faisable. Cette
réduction est rendue possible en retirant de l’INSS certaines informations avant
d’effectuer la transformation et impliquer ces informations pour déterminer la clé
à utiliser.
Ici, chaque fois qu’une nouvelle clé est nécessaire, un candidat devra d’abord être
aléatoirement généré. Ensuite une recherche exhaustive de collision est effectuée.
Lorsqu’aucune collision n’est détectée, la clé candidate est déployée ; sinon, la
procédure est répétée en boucle jusqu’à ce qu’une clé qui convienne soit trouvée.
Il est clair que bien qu'étant (partiellement) one-way, cette construction souffre du
même mal que celle du schéma 4.2.4 (fuite de KeyID).
FIG. 2.5 – Algorithme de conversion d’INSS en HEPI : Schéma modifié avec fonction « one-way ».
25
2.3.3 Conclusion
Il est tout d’abord important de rappeler la raison d’être de l‘HEPI qui est
d’établir un lien entre tous les dossiers patient relatifs à un même patient, dans le
but d’une meilleure organisation et service à la population en matière de soins de
santé.
L’idée de partir de l’INSS, et pas du numéro de registre national par exemple,
vient de la volonté de séparer le domaine de la santé des autres domaines tel que
le domaine administratif.
La solution la plus simple et la plus évidente aurait été d’utiliser carrément l’INSS
comme identifiant de santé. Mais comme montré plus haut, l’INSS ne répond pas
à toutes les conditions soumises à l’identifiant de santé, notamment celui relatif au
fait qu’on ne doit pas pouvoir, au travers de ce numéro, retrouver l’identité du
citoyen en question.
La conclusion à cette étude est qu’il n’y a pas, à notre connaissance, de solution
répondant parfaitement à toutes les contraintes que requiert l’HEPI, lorsqu’on
dérive ce dernier de l’INSS. Ces contraintes sont pour rappel que la génération des
HEPIs :
- doit être irréversible « one-way» ;
- ne doit produire aucune collision, en d’autres termes doit être bijective ;
- doit respecter une contrainte de longueur ;
- doit avoir un espace input limité ;
- ne doit pouvoir être exécuté que par des personnes autorisées.
Malgré qu’aucune solution satisfaisante n’ait été trouvée, la table suivante
présente un ensemble d’algorithmes proposés.
La solution II de cette table est celle qui nous correspondrait le mieux. Cependant,
elle n’offre virtuellement pas de bénéfice par rapport à la solution évidente basée
26
sur la table de conversion et génération aléatoire des HEPIs. Le contraire étant
aussi vrai.
I. Chiffreur symétrique
II. Chiffreur symétrique avec clé améliorée
III. Table de conversion simple (HEPIs cryptés)
IV. Table de conversion avec fonction one-way
V. Schéma hybride de la figure 4.2. 3
Crypto-attaque
Se rapporte à la
sécurité du chiffreur (faiblesse de la 2nd étape)
Se rapporte à la sécurité du chiffreur (amélioration de la 2nd
étape)
Chiffres aléatoires (protection maximale)
Se rapporte
à la sécurité HMAC (élevée)
Brassage de la (faiblesse de la 2nd
étape) et du « IV »
(première étape
améliorée)
Pirate bien informé
HEPI réversible sans efforts
HEPI réversible sans efforts
HEPI réversible sans efforts
HEPI réversible avec efforts
HEPI réversible
virtuellement sans efforts
Mathématiquement réversible
Oui Oui Non Non Partiellement
Longueur de l’HEPI
- 64 bits + Key ID
- 64 bits + Key
ID
+ + > espace INSS
+ >>espace
INSS
- 64 bits + Key
ID
Exemple de longueur de HEPI
15 + 1 2222-
ABCD-EFGH-345C
15 + 1 3333-ABCD-EFGH-345Y
9+1 / 10+1 ABC-DEF-
234-E ABCDE-23456-S
12+1 ABCD-EFGH-2345-Q
15+1 4444-ABCD-EFGH-345R
Stockage de la liste INSS et/ou HEPI
Non Non Oui Oui Non
Peut supporter les changements fondamentaux au format de l’INSS
Oui Oui Oui Oui Limité
TAB. 2.1 –Aperçu des solutions possibles à la génération centralisée des HEPIs [11].
27
2.4 The Bilingual Biclassified Belgian Terminology ou
Thesaurus 3BT
2.4.1 Introduction
L’envie de posséder une information structurée validée dans le secteur
médical n’est pas nouvelle. Déjà des penseurs comme William Farr (1807 – 1883),
premier statisticien médical des services publics anglais écrivait :
« Les avantages d’une nomenclature statistique uniforme, même imparfaite, sont si
évidents qu’il est surprenant qu’aucune attention n’ait été accordée à sa mise en
vigueur dans les tables mortuaires. En de nombreuses circonstances, chaque
maladie a été désignée par 3 ou 4 termes, et chaque terme a été appliqué à de
nombreuses maladies différentes : des noms vagues et impropres ont été employés,
ou bien des complications ont été enregistrées à la place des maladies primitives.
Dans ce domaine de la recherche, la nomenclature est d’une importance aussi
grande que les poids et mesures dans les sciences physiques, et elle doit être établie
sans délai ». [2]
Ajouté à cela, nous nous retrouvons ici face à un problème dû à la composition de
la population du Royaume, d’une part Néerlandophone, d’une autre Francophone
et enfin Germanophone, et face à cela le besoin de couvrir l’entièreté de la
superficie du Royaume en ce qui concerne le partage de données médicales.
En effet, un dossier médical en Français ne serait d’aucune utilité à un médecin
par exemple néerlandophone ne parlant pas le français.
Il se pose en Belgique aussi, au-delà du problème de la langue, celui lié au fait que
les laboratoires n’utilisent pas les mêmes codes pour représenter les données. En
effet, si un hôpital A travaillant avec le laboratoire X envoyait ces données à
l'hôpital B travaillant avec le laboratoire Y, il y a beaucoup de chances que ce
dernier ne sache pas les interpréter.
28
La solution que l’on tente d’y apporter est la création du Thésaurus, qui a pour
missions d’uniformiser la saisie des données médicales qui sont une
représentation du réel par l’écrit en médecine.
Il est donc un outil de structuration de l’information.
Un thésaurus est un système terminologique incluant des synonymes.
Le thésaurus belge 3BT (Bilingual Biclassified Belgian Terminology) est un réseau
sémantique médical ou une terminologie d’interface donnant accès à des libellés
cliniques, diagnostics, problèmes de santé, proches du vocabulaire utilisé
quotidiennement par les médecins.
La sélection d’un libellé induit l’encodage des codes ICPC et ICD ainsi que sa
traduction dans d’autres langues.
2.4.2 Historique
C’est en 1994 que débute, en Belgique, les premiers pas en terminologie
médicale, avec la création de LOCAS-1 basé sur la CISP-1 et comptant quelques
4000 termes médicaux. En 1999 est édité LOCAS-2 basé sur la CISP-2 et comptant
quelques 4500 termes médicaux. Mais les LOCAS ne seront utilisés
quotidiennement que par une dizaine de médecins généralistes dans leur logiciel
médical « PRICARE ».
En 2001, du ministère de la santé, vient la décision de créer un thésaurus avec trois
obligations [2]; le thésaurus doit être :
• belge
• bilingue (français / néerlandais)
• bi-classifié (ICPC-2 / ICD-10 ou CISP-2 / CIM-10)
Le thésaurus 3BT découle du thesaurus ICPC-2 / ICD-10 d’Amsterdam (AT)
acheté par l’Etat belge qui en même temps créa le comité de classification belge,
ayant pour mission de superviser le travail relatif au 3BT.
29
Après consultation de celui-ci, on se rend vite compte qu’il n’y a pas de lien entre
les langues française et néerlandaise. Ce qui rend le thésaurus ICP-2 / ICD-10
d’Amsterdam inutilisable en tant que tel.
D’où la création de l’IBUI (Identificateur Belge Unique – Belgische Unieke
Identificator), qui est un identificateur non codant permettant un repérage
informatique. Dans le même temps débute un travail de traduction qui prit fin en
2003.
Pour répondre à la question de l’utilisation, il a été décidé que le 3BT serait un
outil au service des utilisateurs, c'est-à-dire les médecins généralistes. Le 3BT
devrait dès lors donner accès à des libellés cliniques complets, directement
insérables dans les logiciels médicaux.
C’est suite à cette décision orientant le travail dans une nouvelle direction que la
rupture avec le thésaurus d’Amsterdam (AT) est actée.
Le thesaurus belge (3BT) a pour vocation d’être au service des médecins
généralistes et des patients eux-mêmes, tandis que le thesaurus d’Amsterdam
(AT) est avant tout un outil destiné à la recherche, à l’analyse épidémiologique.
Au moment où ce mémoire est écrit, les travaux sur 3BT ne sont pas encore
achevés, la dernière mise à jour ayant eu lieu en avril 2007.
2.4.3 ICD-10 et ICPC-2
Deux classifications sont employées au sein du thésaurus 3BT : ICD–10 et
ICPC–2. Ces deux classifications sont reconnues au niveau international
(Organisation Mondial de la Santé).
Les deux classifications sont différentes mais néanmoins complémentaires et
permettent une utilisation tant au niveau soins de santé primaire qu'au niveau
secondaire, voire tertiaire.
30
a) ICD-10
ICD–10 signifie « International Statistical Classification of diseases and Related
Health Problems, 10th edition » en anglais et « Classification Internationale des
maladies, 10ème édition » (CIM-10) en français".
Elle fut créée par Farr, dans les années 1890, dans le but de relever les causes de
mortalité à Londres. Régulièrement mise à jour par des médecins de renom et
reconnus par l’OMS, la dixième version a été publiée en anglais en 1992 et a été
traduite dans plus de 20 langues de part le monde.
ICD inclut, dans ses 3 volumes, une liste d’approximativement 17000 maladies
ainsi qu’un index alphabétique.
ICD-10 est organisée autour de deux principes classificatoires : étiologique et
physiopathologique. Elle fait également référence aux localisations
topographiques (Où la maladie sévit) et aux dimensions opérationnelles (test
relatif aux maladies). Ces multiples axes classificatoires font qu’ICD ne peut
éviter certaines redondances.
Les chapitres, codes d’ICD-10 :
chapitre Titre Codes
I maladies infectieuses et parasitaires A00-B99
II tumeurs (malignes, bénignes, indéterminées) C00-D48
III maladies sanguines et immunologiques D50-D89
IV maladies endocrines, nutritionnelles et métaboliques E00-E90
V maladies mentales et du comportement F00-F99
VI maladies du système nerveux G00-G99
VII maladies de l’œil et de ses annexes H00-H59
VIII maladies de l’oreille et du processus mastoïde H60-H95
IX maladies du système circulatoire I00-I99
X maladies du système respiratoire J00-J99
XI maladies du système digestif K00-K93
XII maladies de la peau et des tissus sous-cutanés L00-L99
XIII maladies du système musclo-squelettique M00-M99
XIV maladies du système génito-urinaire N00-N99
XV Grossesse, naissance et puerpéralité O00-O99
XVI certaines pathologies de la période périnatale P00-P96
31
XVII malformations congénitales, malformations et anomalies chromosomiques
Q00-Q99
XVIII symptômes, signes et anomalies cliniques et de laboratoires
R00-R99
XIX traumatisme, empoisonnement et autres conséquences de facteurs externes
S00-T98
X causes externes de morbidité et de mortalité V00-Y99
XXI facteurs influençant la santé et motifs de contact avec les services de santé
Z00-Z99
TAB. 2.2 – Chapitres, codes d’ICD-10 [2].
ICD est donc organisée autour des maladies et de l’activité médicale.
Elle est centrée sur le médecin et sur sa production.
Soutien au « billing system » américain dans sa version ICD-9-CM, elle sert à
l’encodage des RCM (Résumés Cliniques Minimum) dans sa version ICD-9 en
Belgique depuis de nombreuses années.
Le passage à ICD-10 a été décidé par le ministère belge de la Santé Publique en
début janvier 2006.
b) ICPCC-2
ICPC signifie « International Classification of Primary Care » en anglais et
« Classification Internationale des soins primaires » (CISP) en français.
ICPC-1 qui apparaît en 1987 sous l’égide de la Wonca (World Organization of
National Colleges, Academies and Academic Association of General
Practitionners / Family Physicians) est le résultat de près de 15 ans de
recherche en soins primaires.
ICPC-2 a été publié en 1998 et sa forme électronique en 2000.
ICPC, qui est traduit en 20 langues différentes, est organisée sous une forme bi-
axiale.
La grille ci-dessous présente les 2 axes autour desquels ICPC est articulée.
32
TAB. 2.3 – Grille ICPC [2].
ICPC inclut 17 chapitres décrivant un système et est désigné par un code
alphanumérique sur base de la langue anglaise :
• A : général et non spécifique
• B : sang, organes hématopoïétiques et appareil immunitaire
• D : digestif
• F : œil
• H : oreille
• K : circulatoire
• L : ostéomusculaire
• N : neurologique
• P : psychologique
• R : respiratoire
• S : peau
• T : endocrine, métabolisme, nutrition
• U : urologie
33
• W : grossesse, planning familial
• X : génital féminin
• Y : génital masculin
• Z : problèmes sociaux
Les 17 chapitres sont traversés par 7 composants décrivant les échanges entre
un médecin et son patient et désignés par un code numérique à 2 chiffres:
• 1. symptômes et plaintes (0-29),
• 2. procédures diagnostiques et préventives (30-49)
• 3. procédures thérapeutiques et médications (50-59)
• 4. résultats de tests (60-61)
• 5. procédures administratives (62)
• 6. référence et autres motifs de contacts (63-69)
• 7. diagnostics et maladies (70-99)
ICPC comprend environ 750 codes.
ICPC est obligatoire en Hollande, dans les logiciels médicaux des médecins
généralistes belges, ainsi qu'en Norvège. Elle est utilisée aussi bien en Europe
de l’Ouest, qu’en Russie, Chine et Australie. Récemment, les Etats-Unis
d’Amérique ont décidé d’utiliser systématiquement ICPC-2-R (ICPC-2-
Revisited) pour l’enregistrement de leurs données médicales.
ICPC est orientée patient : Chaque code a été développé parce qu’il apparaît
avec une occurrence de ≥1/1000 contacts en médecine générale/de famille. Les
peurs du patient peuvent être relevées ainsi que les handicaps/limitations.
ICPC normalise la globalité de l’approche médicale caractéristique aux soins
primaires (médicale, psychologique, sociologique). Elle n’est pas destinée à
catégoriser le patient mais à comprendre les flux d’informations en soins
primaires.
Il n’y a aucune redondance possible.
34
Les limites d’ICPC : les rubriques des composants 2 à 6 sont très larges et non
spécifiques.
Une classification des médicaments a été développée et publiée pour une étude
européenne mais n’est pas formellement incluse dans ICPC.
Des rubriques résiduelles ou « fourre-tout » se retrouvent à la fin de chaque
section ou sous-section (codes 29 ou 99).
c) ICD / ICPC :
Nous pouvons voir par le Tableau ci-dessous, les principales différences ainsi
que les éléments de complémentarité entre les deux classifications (ICD /
ICPC). Et notamment comment ICD prend mieux en compte le côté "médical"
des pathologies alors qu'ICPC est plus orienté "patient".
Limites et intérêts de ICD et ICPC
ICD est basée sur l’anatomopathologie et les causes de décès
ICPC est basée sur la clinique et le quotidien
ICD est orientée « maladie et médecin » ICPC est orientée « problème de santé et patient »
ICD ne tient pas compte de la prévalence des problèmes et est très granulaire
ICPC tient compte de la prévalence des problèmes et est moins granulaire
ICD est d’utilisation difficile pour les études épidémiologiques
ICPC convient bien aux études micro- et macro – épidémiologiques
TAB. 2.4 – Limites et intérêt de ICD et ICPC [2].
2.4.4. Systèmes terminologiques
Dans ce contexte, il a été proposé d’inclure une terminologie normalisée
étendue dénommée ici thésaurus dans les logiciels médicaux. L’intérêt d’un tel
thésaurus est d’apporter un vocabulaire professionnel normalisé, contrôlé, le plus
exhaustif possible, mais toujours dynamique. Le 3BT est particulier dans sa
conception :
35
Il repose sur un identificateur conceptuel unique par ligne proposée dénommé
IBUI : il s’agit d’un code non signifiant. Il permet de lier à chaque diagnostic un
code ICPC-2, un code ICD-10 et ou d’assurer plusieurs traductions.
Le thésaurus doit permettre de traduire l'ensemble des diagnostics relatifs aux
pathologies rencontrées telles qu'exprimées par les professionnels de santé dans
les "dossiers papier" des malades et de les mettre en relation avec les classifications
CIM-10 (ICD-10) et CISP-2 (ICPC-2).
2.4.5. Composition du 3BT
Les termes de recherche : la table des termes de recherche constitue le
thésaurus belge. Les termes de recherche donnent accès aux libellés cliniques ou
aux libellés des procédures via les IBUIs. Les IBUIs donnent accès aux tables ICD-
10 et ICPC-2. Si un IBUI n’est plus accessible qu’en mode lecture, il se retrouve
dans la table DELETED_IBUIS.
La gestion de ces tables est laissée à l’initiative des développeurs.
FIG. 2.6 – Relations 3BT [3].
Conséquence: l’IBUI correspond à un Labelle Clinique, une entrée ICPC et une
entrée ICD.
36
Conséquence: Un texte Labelle Clinique peut être répété avec différents IBUI (et
avec différentes entrées ICPC et ICD).
Labelle CPC (IBUI): Labelle du code unique ICPC correspondant à l’IBUI.
Labelle ICD (IBUI): Labelle du code unique ICD correspondant à l’IBUI.
Labelle Clinique (IBUI) : Labelle Clinique Unique correspondant à un IBUI.
Liste de mots clés (IBUI): Liste de mots clés Unique correspondant à n IBUI.
Terme (Labelle ICPC): Un mot significatif trouvé dans un labelle ICPC donné.
Terme (Labelle ICD): Un mot significatif trouvé dans un labelle ICD donné.
Terme (Labelle Clinique) : Un mot significatif trouvé dans un labelle Clinique
donnée.
Terme (Liste de mots clés) : Un mot significatif trouvé dans une liste de mots clés
donné.
IBUIS (Terme de Recherche): Tous les IBUI tels que Terme (IBUI) = Terme de
recherche.
Les termes de recherche peuvent se trouver :
a. Dans le libellé clinique relatif à l’IBUI
b. Dans le champ « descriptif » du code ICD-10 relatif au libellé clinique
c. Dans le champ « descriptif » du code ICPC-2 relatif au libellé clinique
d. Dans le champ « termes d’inclusion » du code ICPC-2 relatif au libellé
clinique
e. Dans le champ « notes » du code ICPC-2 relatif au libellé clinique
f. Dans le champ « à considérer » du code ICPC-2 relatif au libellé clinique
Mots Clés TABLE THESAURUS_FR : IBUI 10119470 FR_CLINICA lacération du cœur avec hémopéricarde FR_WORD cardial cardiaque cardio
cœur hémo hémopéricarde hémo-péricarde lacération péricarde
TABLE THESAURUS_NL : IBUI 10100311 NL_CLINICA bronchiale lymfeklier tuberculose NL_WORD tuberculose bronchus bronchial
bronchitis lymfeklier
37
A ce sujet, il est bon de rappeler qu’un des principes de base du THESAURUS est
que la relation
IBUI ↔ LIBELLE CLINIQUE doit être immuable. C’est une des raisons pour
lesquelles un IBUI ne peut jamais être supprimé.
2.4.6 Table de labels Cliniques
IBUI FR_CLINICA NL_CLINICA ICPC-2 ICD-10
10124309 goitre nodulaire toxique
thyrotoxicose bij nodulair struma
T85 E05.1
***********************************************
15001416 dacryocystite syphilitique
luetische dacryocystitis (manifestatie)
F99 H06.0
10115597 dacryocystite syphilitique
Syfilitische dacryocystitis (manifestatie)
F99 H06.0
***********************************************
10095073 hémiplégie d'origine syphilitique
syfilitische hemiplegie Y70 A52.1
10095074 hémiplégie d'origine syphilitique
syfilitische hemiplegie X70 A52.1
TAB. 2.5 – Table des labels cliniques FR- NL 1 [2].
Des procédures ont été ajoutées au thésaurus. Leur IBUI commence
systématiquement par un 4. L’ensemble de ces IBUIS est le résultat du travail
effectué en 2003 et 2004 sur les procédures. Il est utile de préciser que les
procédures retrouvées sont celles qui sont réalisées directement par le médecin
généraliste, ou qu’il demande de réaliser.
38
40001618 référence à un gynécologue
verwijzing gynecoloog *67.105
TAB. 2.6 – Table des labels cliniques FR- NL 2 [2].
2.4.7 Conclusion
Le thésaurus belge 3BT permet à ce que tous les médecins impliqués dans
les échanges de dossier patient électroniques parlent le même langage, qu’ils
soient néerlandophones ou francophones.
Sa mise en application est de ce fait d’une importance capitale. En effet, il n’est pas
très utile d’envoyer un document à un interlocuteur qui ne le comprend pas.
Son caractère « français – néerlandais » est un atout majeur pour l’utilisation à
travers les limites de la Flandre, la Wallonie et la région bruxelloise.
Il n’est, pour le moment pas encore utilisé si ce n’est que pour des tests. ;
39
2.5 Kind Messages for Electronic Healthcare Record –
Belgian Implementation Standard (KMEHR – bis)
Il est tout d’abord important de signaler trois concepts clés qui se trouvent être
importants en ce qui concerne le flux des données médicales :
1. Critères de qualité pour les systèmes informatiques locaux.
2. Standardisation et sécurisation pour les échanges de données médicales
électroniques.
3. Développement du réseau de santé et du dossier de santé partagé.
Il est donc primordial que les échanges de données médicales électroniques soient
standardisés.
KMEHR-bis est le standard XML belge utilisé pour le transfert de message dans le
domaine médical.
XML est recommandé en raison de son acceptation répandue par l’industrie et par
tout le corps international des soins de santé.
La partie normative de KMEHR-Bis n’est composée que de XSchema complété
par la validation XSL-T de KMEHR.
Diagramme du message KMEHR
Une fois que nous avons compris les conventions suivantes :
40
FIG. 2.7 – Diagramme de convention [10].
Diagramme d’élément du KMEHRmessage
FIG. 2.8 – Diagramme de message KMEHR [10].
41
Avec l’émergence des serveurs Web médicaux tel que le serveur régional S3 en
Belgique, le besoin se fait sentir de standardiser les échanges de données entre
serveurs. L’usage d’un Webservice dans ce but est fortement recommandé. Celui-
ci est basé sur une spécification « SOAP » (XML).
Voici une identification des services clés attendus d’un serveur médical :
Nom du service Description
GetTransactionList
C'est un service qui permet à une application d'interroger un serveur Web médical, pour obtenir une liste de transactions (= documents médicaux) qui correspond à un ensemble de critères : l’identifiant unique du patient associé à une combinaison libre de 0, 1 ou plusieurs types de transaction, de 0 ou 1 auteurs, d'une période définie à une date de début et/ou à une date de fin, et de 1 ou plusieurs occurrences. Un serveur médical d'hôpital qui supporte ce service standard de KMEHR peut répondre à la question : « Avez-vous une liste de documents du type « lettre de décharge », plus vieux que 01/01/2001, pour le patient 62031011931. La réponse à une telle question est un ensemble d'en-têtes de transaction dans un élément de réponse KMEHR. L'en-tête de KMEHR contient l'information principale pour chaque transaction comme : l’identifiant unique de transaction de KMEHR, le type de transaction, l’auteur, la date, l’heure, etc.
GetTransactionDetail
C'est un service qui permet à une application d'interroger un web server médical, pour obtenir la transaction complète (= document) qui correspond à l’identifiant unique de transaction de KMEHR. La réponse est un message standard KMEHR encapsulé dans l'élément de réponse.
Typiquement, une application interrogerait le serveur régional avec un GetTransactionList. Ce qui afficherait la liste d'en-têtes de transaction à l'utilisateur. L'utilisateur ferait alors son choix. L'application appellera alors le service de GetTransactionDetail pour accéder entièrement au document, en utilisant son identifiant unique de transaction KMEHR.
PutTransaction C'est un service qui permet à une application de
42
mettre une transaction KMEHR dans un serveur Web médical comme message standard de KMEHR.
Un serveur médical régional qui supporte ce service standard de KMEHR peut recevoir et stocker un message standard de KMEHR.
PutTransactionHeader
C'est un service qui permet à une application de déclarer une transaction de KMEHR dans un serveur Web médical, en utilisant le même élément d'en-tête de transaction que le service de Web de GetTransactionList.
Un serveur médical d'hôpital pourrait déclarer certaines de ses transactions (= les documents médicaux) au serveur régional en utilisant ce service de Web. L'information contenue dans les en-têtes de transaction est employée pour classer le document correctement et pour permettre à des utilisateurs de faire leur choix. Le serveur régional peut rappeler l'URL de l'hôpital du document (qui est stocké dans l'élément de lien) sur demande.
DeleteTransaction C'est un service qui permet à une application de supprimer une transaction de KMEHR d’un serveur Web médical, passant son identifiant unique de transaction de KMEHR. Habituellement le serveur cachera la transaction au lieu de la supprimer physiquement. Un serveur médical régional qui supporte ce service standard de KMEHR peut cacher une transaction sur demande d'une application externe autorisée.
TAB. 2.7 – Services clés attendus d’un serveur médical.
43
2.6 Summarized Electronic Health Record – SUMEHR
Le dossier santé résumé électronique (SUMEHR) correspond à la
photographie sanitaire du patient par son médecin traitant [6]. Il s’agit d’un
instantané que le médecin traitant, en tant que gestionnaire du dossier médical
(global) (DMG), saisira lors de contacts privilégiés avec le patient. Loin d’être
statique, il évoluera donc avec l’histoire médicale de celui-ci. Il ne s’agit donc pas
d’un dossier santé complet, mais bien d’une extraction à partir de celui-ci des
éléments de soins utiles au suivi médical, à une prise en charge effective et à la
continuité des soins.
Le SUMEHR est donc mis à la disposition de plusieurs prestataires de soins qui
pourront le consulter, en tout ou partie, selon des règles d’accès établies lorsqu’ils
ont créé un lien thérapeutique formel avec le patient.
Les logiciels de médecine générale homologués par le SPF Santé Publique en 2006
ont la capacité de produire (exporter) et d’intégrer (importer) de manière
standardisée des fichiers électroniques contenant les données du SUMEHR. Pour
exploiter également ceux-ci, les institutions de soins doivent à leur tour adapter
leur DMI.
Le fichier qui transporte les données du SUMEHR est un message qui fait partie
d’un ensemble de messages développés à l’initiative du SPF Santé Publique,
normalisant ainsi les principales transactions médicales (lettre de sortie, notes de
liaison, protocoles médico-techniques, etc.). Pour que le dialogue soit possible, il
faut que les différents interlocuteurs parlent un même langage, en l’occurrence
XML-KMEHR qui en constitue la syntaxe et la grammaire. XML-KMEHR est le
garant d’une standardisation, codification comprise, compatible et convergente
vers un standard européen futur.
Le SUMEHR est composé des rubriques suivantes:
• Date de création ;
• Auteur ;
• Identification (qui devrait être le HEPI) ;
44
• Présentation du patient : nom, prénoms, date de naissance, sexe, langue
parlée ;
• Personne de contact ;
• Risques : allergies, réactions adverses de médicaments, facteurs sociaux,
autres facteurs ;
• Antécédents personnels pertinents : IBUI et ICPC2 et ICD10 (IBUI vide est
permis), date de début, date de fin, texte ;
• Liste des problèmes actuels : IBUI et ICPC2 et ICD10 (IBUI vide est permis),
date de début, texte ;
• Médications pertinentes : CNK ou autre identifiant (cas d’absence de CNK),
informations sur l’administration, instruction pour le patient, date de
début, date de fin, texte ;
• Statut de vaccination :
o Administrée : CNK et/ou ATC, date
o A administrer : CNK et/ou ATC, date
• Commentaire contextuel.
45
2.7 Réseaux médical Belge
Les échanges de données dans le secteur médical en Belgique ne sont pas encore
réglementés.
Ainsi nous pouvons remarquer des regroupements de médecins, parfois sous
forme d’ASBL, dans le souci de rendre possible ces échanges de données
médicales, de faciliter la tâche des professionnels de santé et d’améliorer la qualité
des soins aux patients.
Avant d’aller plus loin dans les échanges de DMI il est important de distinguer le
Courrier Médical qui est le résumé d’une consultation ou informations notées par le
médecin, du Dossier Médical, ce dernier comprenant en plus du courrier médical
les impressions et notes personnelles faites à partir des observations du médecin.
Le dossier médical est strictement confidentiel et appartient au médecin qui l’a
créé.
En Belgique et dans une grande partie du reste du monde, une loi stipule que
chaque patient a le droit de consulter son courrier médical.
Le dossier médical lui fait l’objet du secret médical.
Nous distinguons différentes topologies de réseaux selon que l’on se trouve en
Flandre, en Wallonie ou dans la région Bruxelloise.
a) En Flandre
En Flandre, nous observons la tendance qui est de rassembler les cabinets
médicaux autour des hôpitaux, ou cliniques qui sont eux-mêmes rattachés à
de grands hôpitaux pour la plupart universitaires.
46
FIG. 2.9 – Réseaux d’échanges de données médicales en Flandre.
b) En Wallonie
En Wallonie, les médecins se regroupent en ASBL de télématique médicale.
Cette dernière est chargée de l’enregistrement des médecins inscrits à l’INAMI
et de la vérification de leurs aptitudes à exercer (s’ils n’ont pas été radiés par
exemple) lorsque ceux-ci demandent des informations. L’ASBL se charge aussi
de sécuriser les échanges entre médecins, hôpitaux et laboratoires.
c) A Bruxelles
A Bruxelles, un peu comme en Wallonie, les centres de santé, et les cliniques se
regroupent et créent des organisations dans le but d’avoir un Portail où les
médecins pourront se connecter et accéder à un partage de dossier médical de
façon sécurisée entre médecins ayant un lien thérapeutiques avec le patient en
question.
47
Concrètement, en Belgique, les médecins belges font appel à des compagnies
spécialisées pour répondre à leurs besoins d’échange de dossier médical
informatique. MEXI et MediBridge sont deux de ces compagnies utilisées par
plusieurs médecins belges.
Le principe est de s’inscrire à l’une de ses compagnies. Cette dernière possède
ainsi une table avec tous les abonnés et leur adresse IP. Une fois qu’un médecin
s’est authentifié, et veut envoyer une information à un autre médecin, il peut
retrouver son adresse chez sa compagnie et la lui envoyer. Le message est envoyé
de façon crypté par le canal de sa compagnie, auprès duquel il a au préalablement
loué une bande passante d’une capacité variant en fonction du prix de location.
C’est la compagnie qui se charge de garantir que le message est sécurisé par un
canal HTTPS et qu’il arrive à bon port. Il faudrait auparavant que l’expéditeur et le
récepteur soient tous deux enregistrés auprès de la compagnie.
Certaines compagnies gèrent même les incompatibilités de logiciel, c'est-à-dire
qu’elles se chargent elles-mêmes de traduire le message dans un langage que le
récepteur comprenne.
Une fois le message arrivé, le serveur généralement se vide, et ainsi ne conserve
pas en son sein les messages échangés.
Le numéro de registre national est par défaut utilisé pour l’identification des
patients.
Plusieurs logiciels sont utilisés par les hôpitaux et cliniques, parmi lesquels nous
pouvons citer : Medidoc, Medigest, ACTH,Epicur etc.
48
Chapitre 3
Echanges de données dans le secteur médical à
l’étranger
3.1 Introduction
D’autre pays tels que l’Angleterre, la Finlande, les Pays Bas, La Norvège,
l’Espagne, l’Israël, et les USA, ont déjà développé un système d’échange de
données dans le secteur médical ayant quelques similitudes entre eux mais tout de
même différents selon l’environnement dans lequel ils se trouvent.
On peut séparer ces pays en deux groupes qui constituent un choix majeur dans la
façon de stocker les données médicales : « systèmes centralisés et systèmes
décentralisés »
3.2 Système centralisé
Le système centralisé se caractérise par le stockage dans une grosse base de
données de tous les dossiers médicaux. En effet, dans ce système, lorsqu’un
dossier médical est créé, une copie de ce dernier est envoyée dans une grande base
de données qui la stocke et en gère l’accès.
49
Angleterre
La NHS (National Health Service) qui est l’organe suprême de santé en
Angleterre a mis en place le NationalProgramme for IT (NPFIT) chargé entre autre
de piloter le projet visant à connecter les 30.000 médecins généralistes et 300
hôpitaux que compte l’Angleterre.
Le NPFIT est un système fortement centralisé, avec un accès aux données sécurisé
et réservé aux professionnels de santé ayant ce droit.
Il est aussi prévu dans la continuité de ce projet que les patients puissent avoir
accès à leurs dossiers médicaux à travers un service en ligne sécurisé appelé
« HealthSpace » [14]
Les médecins ou centres de santé sont censés envoyer au système leurs dossiers
médicaux informatiques. Celui-ci les stocke et les met à la disposition de tous les
autres médecins inscrits dans ce programme d’échange.
En contrepartie, ces médecins reçoivent du système des informations de données
statistiques utiles à leur travail.
FIG. 3.1 – Système centralisé des échanges de données médicales.
50
On aurait tendance à croire, à première vue et selon bon nombre d’informaticiens
travaillant sur le sujet, que ce système n’est pas viable à long terme.
Mais avec de plus amples réflexions, nous pensons qu’il est tout à fait viable dans
la mesure où l’on prévoirait un espace de stockage assez grand et où l’on aurait
une prévision de ce que sera le nombre de dossiers à l’avenir.
Si l’on créée un nouveau dossier médical à la naissance de chaque patient, qui est
seulement mis à jour tout au long de sa vie et qui n’est plus utilisé après la mort de
ce dernier, le problème d’espace sans cesse fortement croissant est donc résolu.
Dans ce cas, ce système laisse apparaître les avantages d’une gestion centralisée,
en ce qui concerne notamment le temps de réponse à une requête, la gestion et
l’implémentation qui sont nettement plus simples.
3.3 Systèmes décentralisés
Le système décentralisé est le contraire du système centralisé.
Dans celui-ci, les dossiers médicaux ne sont pas stockés dans une grande base de
données. Chaque dossier reste là où il a initialement été créé, et le système ne
garde qu’une référence faisant effet de connaissance de la présence de ce dossier et
de l’endroit où il se trouve.
3.3.1 Les Pays Bas
Le maître d’œuvre des échanges de données dans le secteur médical aux
Pays Bas est l’institut gouvernemental NICTIZ (« Nationaal ICT Institut in de
Zorg » ou en francais, « Institut National pour l’informatisation des Soins de
Santé »).
Ce projet d’échanges de donnée dans le secteur médical aux Pays Bas, s’intitule
« LSP » (« Landelijk Schakel Punt » ou « Point d’Accès National »).
51
NICTIZ est responsable de la définition fonctionnelle du projet, des choix
techniques de haut niveau, et du suivi général. Il sous-traite aussi le reste du
travail, dont l’implémentation, avec différentes sociétés telles que CSC et
InterSystem. C’est de ce dernier que nous tirons la plupart des données présentées
ci-dessous.
Bien que la gestion et le financement soient centralisés, le choix d’un modèle
décentralisé va influencer toute la manière dont ce projet a été mené jusqu’ à
présent.
Il en résulte que:
- Les données médicales ne sont pas stockées dans le LSP
- Le LSP accède aux données médicales in situ
- Le rôle du LSP n’a donc pas une connaissance des dossiers médicaux, mais
une connaissance de la localisation de l’information (c’est donc un centre de
« meta information »).
Forte d’une grande expérience dans le domaine, suite aux projets antérieurs,
NICTIZ a imposé certaines conditions dans l’implémentation du projet.
Telles que :
• L’utilisation d’une infrastructure de communication unique basée
sur la technologie des services Web
• L’utilisation du format de données médicales HL7 version 3
• L’utilisation d’une sécurisation de transport de données basée sur la
norme HTTPS
Tout ceci nous donne le schéma suivant :
52
FIG. 3.2 – LSP [1].
1 : L’utilisateur final communique avec le GBZ au moyen d’un protocole
quelconque
2 : Fournisseur de soins de santé « bien géré »
3 : Réseau de communication de données
4 : Le GBZ communique avec le ZIM en HL7v3, au moyen de SOAP sur HTTPS
3.3.1.1 Fonctionnement : Scénario
Etape 1 :
1 : M. Dupont est admis à l’hôpital « x » d’Amsterdam
53
FIG. 3.3 – LSP, scénario 1 [1].
2 : Le dossier de M. Dupont est ainsi stocké dans le GBZ. Celui-ci peut être géré
par l’hôpital « x » lui-même, ou par une association d’hôpitaux
3 : Le ZIM note que L’hôpital « x » dispose de données administratives sur M.
Dupont
Etape 2 :
1 : M. Dupont passe une radiographie à la clinique « y » d’Amsterdam
54
FIG. 3.4 – LSP, scénario 2 [1].
2 : Le GBZ peut être géré par une société de services indépendante
3 : Plusieurs GBZ peuvent utiliser le même DCN
4 : La clinique « y » dispose de données médicales sur M. Dupont
Etape 3 :
1 : M. Dupont, en visite à Rotterdam, est victime d’un malaise; un médecin
local désire consulter son dossier médical
55
FIG. 3.5 – LSP, scénario 3 [1].
2 : Le GBZ peut être géré par une association régionale de praticiens
3 : Le ZIM recompose les réponses en un seul message
4 : Les GBZ de l’hôpital « x » et de la clinique « y » disposent de données
médicales sur M. Dupont
3.3.1.2 Sécurité
Les données en transit sont sécurisées par le transport sur HTTPS (SSL,
utilisation du chiffrage AES)
3.3.1.3 Authentification
Une décision politique préparatoire a créé le numéro registre national « BSN »
(Burger Service Nummer) celui-ci est une extension du système existant
« SOFI » et inclut les personnes présentes sur le territoire national à titre
temporaire.
56
Les professionnels eux sont identifiés par un système de carte à puce « UZI-
Pass » (identification Unique de Prestataire de Soins).
Celui-ci est basé sur une technologie « Javacard » et génère un certificat X509
valide, utilisé directement par la communication HTTPS pour l’authentification
et la non répudiation.
FIG. 3.6 – UZI –Pass [1].
Les règles qui définissent l’étendu des droits des intervenants sont programmées
dans le logiciel sous forme d’un diagramme décisionnel.
- Le patient peut entièrement refuser l’accès à son dossier
- Le patient peut décider que son dossier ne soit accessible que dans les cas
d’urgences
- En fonction du profil du demandeur, certaines informations peuvent ne pas
être pertinentes. Par exemple, une personne administrative ne doit pas
pouvoir accéder à un dossier médical
57
3.3.1.4 Cycle complet
FIG. 3.7 – LSP, cycle complet [1].
1 : Détermine l’identité et la qualité du demandeur par le moyen de l’UZI-Pass
2 : Détermine l’identité du patient sur base de son BSN par le moyen du numéro
BSN
3 : Sur base de l’identité du demandeur et du patient, ainsi que des circonstances
(urgence ou pas), la transaction est autorisée
4 : Ces communications sont encryptées au moyen de SSL et contiennent le
certificat extrait de l’UZI-Pass.
58
Chapitre 4
Modélisation d’un réseau d’échanges de
données dans le secteur médical en Belgique
4.1 Introduction
Nous tenons tout d’abord à souligner le fait que nous travaillons en
Belgique avec les avantages (facilités d'atteinte des personnes travaillant sur le
sujet, étendue du pays relativement limitée, etc.) et les inconvénients (plusieurs
langues de travail, lenteur dans la prise de décision compte tenu des nombreux
gouvernements, etc.) que cela implique.
La première chose que nous pouvons remarquer est le fait que chaque pays à une
approche du problème se rapportant à sa législation, au nombre de centres de
santé à gérer, aux priorités fixées, et à d‘autres critères qui lui sont propres. D'où,
il n’y a pas de solution optimale universelle mais plutôt une solution optimale
« locale », adaptée à chaque Pays.
Ainsi, nous ne pouvons copier une solution étrangère et essayer de l'adapter à la
Belgique. Elle souffrirait alors de beaucoup de maux.
59
Le Type de modèle de fonctionnement que nous nous proposons d'approfondir
dans cette étude est celui basé sur une approche décentralisée, où chaque centre de
santé possède ses propres bases de données et est relié aux autres centres de santé
grâce à un serveur central qui va gérer les accès à l'information.
4.2 Approche générale
La clé de notre démarche est le fait de se baser sur un model décentralisé ;
c'est-à-dire que les données ne sont pas stockées dans une grande base de donnée
gardée à un endroit précis, mais que chaque centre de santé garde ses données et
les médecins se servent du système uniquement pour le partage d’informations.
Le choix de ce système décentralisé présente les avantages et inconvénients
suivants :
a) Avantages :
• Relative simplification du système central
� Volume de stockage beaucoup moins important
• Les données obtenues sont toujours « à jour »
� Pas de latence de synchronisation
� La seule contrainte de synchronisation est l’indication qu’un
nouvel intervenant détient une partie du dossier d’un patient
• Décentralisation de validité de données et de temps d’accès.
� Simplification légale : pas de morcellement de la
responsabilité sur les données.
• Sécurité :
� Le fait de ne pas avoir tous les dossiers médicaux stockés au
même endroit accroît la sécurité.
60
b) Contraintes :
• Le volume de transfert de données dans son ensemble sur
l’infrastructure est important
• Le temps de réponse à une requête client est dépendant des
fournisseurs de données
• La gestion est plus complexe que celle, par exemple, d’un système
centralisé.
Il se traduit par le schéma suivant :
FIG. 4.1 – Schéma des échanges de données dans le secteur médical.
61
Chaque GF (Groupe Fonctionnel) a sa propre base de données dans laquelle il
stocke ses données et en gère l'accès de façon indépendante. Peu importe la
manière dont chaque GF identifie ses médecins; ce qui nous intéresse est que
quand un médecin X d'un GF A se connecte, que le GF puisse nous confirmer son
identité.
4.3 Groupe Fonctionnel : GF
4.3.1 Présentation
Un groupe fonctionnel (GF) peut représenter un hôpital, une clinique, un
groupe de cabinet médicaux, un centre médical etc.
FIG. 4.2 – Groupe fonctionnel.
GF est le nom de propriété donné à un système informatique d’un hôpital, centre
de Santé, clinique respectant tous les critères nécessaires à la bonne marche des
échanges de données.
62
Le choix du SGBD (Système de Gestion de Base de Données) utilisé pour la gestion
des GF est libre et dépend du centre de santé ou hôpital en question.
Il peut se rapporter au nombre d’ordinateurs à gérer par le SGBD et à d’autres
facteurs laissés à l’appréciation de leurs équipes informatiques.
Cependant, pour qu’un GF soit reconnu comme tel, il lui faudra remplir certaines
conditions sans lesquelles tout le système ne pourrait fonctionner correctement.
Un GF doit :
1. Etre à tout moment accessible : Il est important qu’à n’importe quel
moment du jour ou de la nuit, une information puisse être demandée et
extraite d’un centre médical. Le serveur central peut être sollicité en tout
temps et celui-ci doit pouvoir rassembler toutes les informations
nécessaires provenant des GF en tout temps également.
2. S’assurer de la disponibilité de toutes les données : le GF doit s’assurer
qu’il a accès à tous les dossiers qu’il est sensé pouvoir pourvoir. Ainsi, il
doit s’assurer de la persistance des données dans le temps.
Le GF doit prévoir le fait que si les informations sont au fil du temps
stockées sur plusieurs disques dur, que toutes ces dernières soient
toujours accessibles avec les mêmes conditions pour garder
l’exhaustivité du dossier patient.
Il doit aussi assurer la perpétuité de toutes les données même en cas de
crash du disque dur.
3. Utiliser le Web service de KMEHR pour l’envoie des données : Ici, le
choix du KMEHR est justifié par le fait qu’il est impératif que les centres
de santé parlent le même langage. KMEHR est le langage qui a été
63
adopté comme celui qui sera, lorsque opérationnel, le langage de base
des échanges de données médicales en Belgique.
4. Souscrire aux règles de codage du Thésaurus 3BT : Ceci est encore une
fois justifié par le fait qu’il faut parler le même langage. Cela ne servirait
à rien d’envoyer des messages à un interlocuteur qui ne peut les
comprendre. Et ce serait fastidieux des deux cotés de devoir à chaque
communication envoyer un dictionnaire à son interlocuteur pour qu’il
puisse déchiffrer ce que l’on veut dire.
5. Avoir un temps de réponse à la requête inférieur à 5 secondes : Ceci
est imposé pour des raisons de rapidité. En effet, le temps de réponse
des GFs à une requête doit être suffisamment court.
4.3.2 Mesures à prendre afin que la propriété GF soit respectée
1. Etre à tout moment accessible : Il faudra s’assurer que la base de données
soit accessibles 24h/24h, que la machine soit toujours en marche et connectée,
pouvant ainsi assurer à tout moment un transfert de données s’il le lui était
demandé.
2. S’assurer de la disponibilité de toutes les données : Nous sommes certains
que la donnée se trouve bel et bien là vu que tout se stocke au même endroit et
que c’est à cette source que l’on a accès.
Le problème que l’on doit prévoir est celui où l’on aurait à faire à un cas de
crash de disque dur.
Une des solutions les plus simples demeure la présence d’un second disque
dur dans lequel la première serait dupliquée.
64
3. Utiliser le Webservice de KMEHR pour l’envoi des données : Cela équivaut
uniquement à installer et mettre en application KMEHR. Pour cela les
machines doivent être dotées de certaines performances.
4. Souscrire aux règles de codage du Thésaurus 3BT : Utiliser simplement les
codes du thésaurus 3BT pour la nomenclature.
4.4 Serveur Central: National Health Connect Exchange
(NHCX)
4.4.1 Presentation
Le NHCX est le Serveur national unique qui joue le rôle de véritable chef
d’orchestre des échanges de données dans le secteur médical.
FIG. 4.3 – National Health Connect Exchange Server (NHCX).
65
Comme nous le montre la figure 6.3, le dossier médical informatique n’est pas
stocké dans une base de données rattachée au serveur comme c’est le cas dans les
systèmes centralisés.
Dans notre cas précis, il n’est stocké dans le système central que les informations
de créations et mise à jour de DMI et les informations sur les prestataires de soins
de santé, ce qui implique que nous travaillons dans un système décentralisé.
Le choix d’opter pour un système décentralisé a été motivé par les avantages que
nous lui avons trouvés par rapport aux systèmes centralisés et « peer to peer ».
4.4.2 Tables gérées par le NHCX
Dans notre implémentation, le NHCX gère deux grandes tables :
- la table des patients (Patients), contenant un index sur les DMI du
royaume ;
- la table des serveurs (Server Entry), contenant les adresses des serveurs.
4.4.2.1 La table Patients
La table Patients est une grande table comprenant deux entrées principales,
un numéro HEPI et une liste d’id serveur. Elle est mise à jour chaque fois
qu’un DMI est créé dans un hôpital, cabinet médical, laboratoire etc.
Cela peut se faire par exemple par un trigger dans la base de données des
GFs.
Ou encore gérée par le logiciel des GF, lorsqu‘un DMI est créé, lors de
l’enregistrement de celui-ci, un message est envoyé au serveur contenant le
HEPI du patient pour lequel un DMI vient d’être créé, l’endroit (ID du
serveur de l’hôpital) où l’opération vient de s’effectuer.
D’où le serveur complète sa table « patient ».
66
Les champs de la table des patients :
HEPI : (entier) Il s’agit du numéro HEPI des patients ayant au moins une
fois consulté un médecin.
idServeur : (entier) Il s’agit de l’identité du serveur qui a envoyé
l’information concernant la présence dans son sein d’un dossier médical
informatisé concernant le patient susmentionné.
La clé primaire est l’HEPI.
4.4.2.2 Table des Serveurs « ServerEntry »
Cette table stocke les informations concernant tous les serveurs enregistrés
comme GF et leurs IP. Elle est mise à jour « physiquement » lors de
l’enregistrement d’un GF ou de modification d’information le concernant.
Les champs de la table des patients :
ID : l’identifiant du serveur
IP : l’adresse IP du serveur
La clé primaire pour cette table étant idServeur.
Le NHXC joue un rôle de relayeur d’information et de requête, et n’a donc pas
besoin de contenir plus d’information à notre niveau.
Il doit être capable de dire où se trouvent les dossiers patients et de les regrouper
pour les renvoyer au GF qui en a besoin. Pour ce faire, les seules informations qui
lui sont nécessaires sont donc l’information de présence d’un dossier et son
adresse pour savoir où les trouver.
67
Mais nous implémenterons ici le NHCX de sorte à ce que si dans le futur d’autres
tâches lui sont rattachées, que cela puisse être implémenté sans difficultés.
4.5 Authentification
Les systèmes d’authentifications des médecins dans les différents centres de
santé, hôpitaux, cliniques sont bien élaborés et fortement diversifiés.
Nous proposons, au lieu de faire table rase de cet acquis et de chercher à doter
tous les centres de santé d’un moyen d’authentification uniforme, ce qui par
ailleurs coûterait cher, de se baser sur cet acquis pour nous permettre d’avancer
plus vite.
Nous faisons alors, à juste titre, confiance aux centres de santé sur la façon de
reconnaître leurs médecins.
Ainsi, lorsqu’un médecin quelconque se connecte au système, la chose qui nous
importe à ce moment là est que le GF auquel il appartient puisse nous confirmer
son identité.
Les médecins travaillant seuls, pourront soit se rattacher à un GF, ou se grouper às
d’autres médecins pour former un GF, dans le cas, fortement probable, où ils ne
pourraient à eux tout seul être un GF.
Les hôpitaux peuvent utiliser différents types de sécurité: (login-password,
digipass, empreintes digitaux ou reconnaissance par inspection des yeux, cartes à
puces, etc.)
68
4.6 Scénarios
1) Lorsque le patient se présente chez son médecin, celui-ci crée son courrier
médical comme de coutume, avec comme seule nouveauté le numéro
d’identification personnel du patient qui est le même dans tous le royaume
(HEPI).
Lors de l’enregistrement du courrier médical, un message est envoyé au NHCX
contenant l’id du GF et le HEPI du patient en question.
Il en est de même d’un rapport enregistré par un laborantin ou tout autre
professionnel de santé habilité à le faire.
Une exception est faite lorsqu’il s’agit d’un patient ayant expressément indiqué
qu’il ne voulait pas que son DMI soit partagé.
2) Lorsqu’un professionnel de santé veut consulter le dossier médical d’un patient.
Il le fait à partir de son GF en envoyant une requête au NHCX.
Cette requête contient le HEPI du patient dont on veut consulter les DMI, l’ID du
GF, tous les renseignements permettant d’identifier le médecin demandant (son
numéro INAMI suffit) et optionnellement des informations permettant de détailler
la recherche (Par exemple, les dossiers contenant une radio, dans le cas ou
médecin voudrait connaître l’évolution radiographique de son patient).
3) Lorsque la requête arrive dans le NHCX, celui-ci vérifie la provenance de cette
dernière.
Si la vérification est un succès, il recherche dans sa table des patients les adresses
IP des GFs contenant des informations sur le patient en utilisant, comme clé
primaire, l’id patient (HEPI).
Le NHCX crée des tunnels HTTPs avec les GF concernés et y puise les DMI relatifs
au patient.
IL les regroupe, prenant en compte les détails, s’il y en a, de la requête, et les
renvois au demandeur en format KMEHR.
Le Serveur met à jour un fichier historique tenant compte de tout ce qu’il fait.
69
Chapitre 5
Implémentation
5.1 Introduction
Dans le cadre de ce mémoire, nous présentons notre vision de comment
pourrait être implémenté le NHCX afin de répondre aux exigences qui sont les
siennes.
Nous ne présenterons pas ici le flux d’information du NHCX vers les GFs dans un
tunnel HTTPs.
Le but recherché premièrement dans notre implémentation est de produire un
code clair et facile à comprendre dans le sens où étant donné le caractère
changeant des lois dans ce domaine, il puisse être facilement compris et maintenu
par n’importe quel informaticien pourvu qu’il connaisse le design Pattern java
utilisé.
5.2 Modèle Vue Contrôleur (MVC)
5.2.1 Introduction
Notre code se base donc sur une architecture Modèle Vue Contrôleur 2 (MVC 2)
ce qui implique dans notre implémentation une séparation en trois parties
comprenant :
- les données
70
- les traitements
- la présentation.
Une des définitions données pour expliquer le fonctionnement du MVC est la
suivante :
La vue, correspond à l'interface avec laquelle l'utilisateur interagit (IHM). Aucun
traitement n'est effectué dans la vue, elle sert uniquement à afficher les données et
permettre à l'utilisateur d'agir sur ces données.
Le modèle, représente les données et les règles métier. C'est là que s'effectuent les
traitements. Les bases de données en font partie, de même que des objets tels que
les EJB et composants ColdFusion. Les données renvoyées par le modèle sont
indépendantes de la présentation, c'est-à-dire que le modèle ne réalise aucune
mise en forme. Les données d'un seul modèle peuvent ainsi être affichées dans
plusieurs vues. Cette capacité permet de factoriser le code, car le code du modèle
n'est écrit qu'une seule fois puis réutilisé par toutes les vues.
Le contrôleur, interprète les requêtes de l'utilisateur et appelle le modèle et la vue
nécessaires pour répondre à la requête. Ainsi, lorsque l'utilisateur clique sur un
lien ou soumet un formulaire HTML, le contrôleur ne produit rien et n'effectue
aucun traitement. Il intercepte la requête et détermine quels modèles et quelles
vues doivent être associés.
Pour résumer, une requête utilisateur est interprétée par le contrôleur, qui
détermine quelles portions du modèle et de la vue doivent être appelées. Le
modèle gère les interactions avec les données et applique les règles métier, puis
renvoie les données. Enfin, le contrôleur sélectionne une vue et lui passe les
données.
71
FIG. 5.1 - Modèle MVC (Model Vue Contrôleur).
Nous avons choisi d’utiliser le MVC2 qui est une nouvelle version du MVC, car ce
dernier peut être lourd à mettre en place à cause de la multitude de contrôleur à
implémenter. Le MVC2 est une simplification de MVC, avec exactement le même
modèle de conception à la différence qu’il n’y a plus qu’un seul contrôleur qui se
charge de rediriger la requête vers le bon traitement.
Pour mieux comprendre l’implémentation il est important de passer par une brève
explication des frameworks qui constituent l’ossature de notre architecture MVC2.
Il s’agit de :
- hibernate
- spring
- struts
Hibernate, est un open-source qui gère la persistance des objets en base de
données relationnelle. C’est une solution ORM (Objet-relational mapping)
72
fournissant un framework facile à utiliser pour mapper un model Orienté Objet à
une base de données relationnelle traditionnelle.
Spring, est une infrastructure similaire à un serveur d'application J2EE. Il prend
donc en charge la création d'objets et la mise en relation d'objets par
l'intermédiaire d'un fichier de configuration qui décrit les objets à fabriquer et les
relations de dépendances entre ces objets.
Le gros avantage par rapport aux serveurs d'application est qu'avec SPRING, les
classes n'ont pas besoin d'implémenter une quelconque interface pour être prises
en charge par le framework. Cet aspect lui vaut la qualification de conteneur «
léger ».
En outre, SPRING propose tout un ensemble d'abstractions permettant de gérer
entre autres le mode transactionnel, l'appel d'EJBs, la création d'EJBs, la
persistance d'objets, la création d'une interface Web et l'appel et la création de
WebServices.
Apache Struts, est un framework open-source servant à développer des
applications web J2EE.
Il utilise et étend l'API Servlet Java afin d'encourager les développeurs à adopter
l'architecture Modèle-Vue-Contrôleur. Cette infrastructure permet la conception et
l'implémentation d'applications Web de taille importante et d'être gérées par
différents groupes de personnes. En d'autres termes, les designers, développeurs
de composants logiciels peuvent gérer leur propre part du projet de manière
découplée.
Struts permet d'automatiser la gestion de certains aspects comme par exemple la
validation des données entrées par les utilisateurs via l'interface de l'application.
Struts montre toute sa puissance dans des applications d'une certaine envergure,
auxquelles il convient le mieux.
73
5.2.2 Interface Lors du démarrage de l’application Care Receiver Search, la première fenêtre à
apparaître est celle illustrée par la figure 5.1. Il s’agit ici d’un simple écran
d’acceuil à partir duquel on va démarrer l’ensemble de l’application qui consiste
donc à la recherche d’information à partir d’un id patient.
FIG. 5.2 – Ecran d’accueil de l’application Care Receiver Search.
La fenêtre illustrée à la figure 5.2 apparaît en second lieu pour nous permettre
d’introduire le numéro HEPI du patient dont on recherche les informations.
74
FIG. 5.3 – Ecran de recherche de l’application Care Receiver Search.
Le fait de cliquer sur rechercher fait appel à la fonction SearchPatient qui reçoit en
entrée le HEPI du client et va rechercher dans la table Patient l’endroit où se
trouve les informations concernant le dit Patient et les retourner sous la forme
suivante :
75
FIG. 5.4 – Résultat de la requête Care Search Receiver.
Le format de la fiche médicale ci-dessus est celui de notre test. Idéalement, le
SUMEHR devrait apparaître après une telle requête.
5.2.3 Notre implémentation
Ci-dessous, la figure de notre implémentation représentant chaque partie
de notre modèle MVC ainsi que nos principales classes.
76
FIG. 5.5 – Subdivision du modèle MVC (Modèle Vue Contrôleur).
a) Objets
Les objets sont générés et mappés par hibernate.
Il s’agit ici des fichiers :
- *.hbm.xml, en occurrence : les deux fichiers Patient.hbm.xml et
entryServers.hbm.xml
- crs-application-context.xml
- *.properties
77
- *.jdbc
Tous ces fichiers sont nécessaires pour mapper table � objet et
configurer le tout.
C’est dans les fichiers crs-application-context.xml et *.properties que nous
configurons et initialisons le tout.
En plus de tout cela, Hibernate génère et utilise nos objets Patient.java et
EntryServer.java
b) Data Access Object (DAO)
Les DAO (Data Access Object) sont nécessaires dans la mesure où ils nous
empêchent de manipuler directement les objets et ceci toujours dans un
souci de découper en couches « layers » l’implémentation.
Ainsi, la « logique business » (tout ce qui concerne l’aspect métier de
l’application) et la création de nouveaux objets sont indépendantes l’une de
l’autre.
Le DAO est une sorte de représentation intermédiaire de l'objet qui encapsule toute la logique d'accès (Sql par vulgarisation) propre à chaque entité.
Les fichiers qui se rapportent aux DAO sont :
- *DAO.java
- *DAOImpl.java (EntityDAOImpl.java ; ServerEntryDAOImpl.java ;
PatientDAOImpl.java). EntityDAOImpl.java est une classe générique
pour les types d’opérations communes à tous les objets (update, delete,
insert,…).
PatientDAOImpl.java et EntryServerDAOImpl.java sont des « extend »
de la classe EntityDAOImpl.java.
La méthode déclarée dans EntryServerDAOImpl.java permet de
rechercher l’IP d’un proxy server en fonction de l’ID (HEPI) d’un
patient. Elle n’est, par conséquent, pas une « opération/méthode »
nécessaire à tous les objets.
- et le fichier Spring, crs-dao-context.xml
78
c) Manager et Service
Dans l’application que nous implémentons, nous aurions pu nous passer
des étapes « manager » et « service ». La raison pour laquelle nous avons
jugé nécessaire de les avoir est due au fait qu’ils sont nécessaires dans le
cadre de l’application complète et donc plus complexe des échanges de
données dans le secteur médical, idem pour les services.
En effet, on encapsulerait dans les managers toute la logique métier
"business" ; comme l'appel/l'interaction, l'interprétation et le process flow
des différents DAO et de leur résultat. Si un nouveau busines process/flow
venait à être créer, le développeur devrait le mettre dans le manager et les
objets utilisés dans *.objets et DAO.
Pour « Service », on se base sur le fait que plusieurs managers peuvent
interagir entre eux et qu’on peut alors encapsuler tout ceci dans un service.
Le service étant normalement une interface déclarative des opérations
proposées. Mais tout ceci est, effectivement, un « nice to have » qui n’est
pas forcément obligatoire dans une petite application, mais qui, dans notre
cas, est nécessaire dans un souci de découper en couches « layers »
l’implémentation.
Un point de vue autre placerait le manager et le service dans « Controller «
au détriment de « Modèle » car c'est eux qui contrôlent l'utilisation des
objets Java.
d) Controller et Vue
Ici, le fichier que nous retenons comme étant le plus important est le fichier
« Struts-config.xml ». C'est lui qui fait le lien entre toutes les classes gérées
par Struts. Il assure donc le rôle effectif du Contrôleur en superposition
avec Spring.
Spring joue aussi le rôle de contrôleur dans le sens où, comme Struts, il
nous dit quel objet est instancié lorsque nous appelons telles ou telles
classes.
79
Nous pouvons ici définir l’enchainement suivant :
jsp -> fichier form -> fichier Controller orchestrer, configurer et initialiser
par le fichier Struts-config.xml.
En d’autres termes : c'est Struts qui lie une jsp à un formulaire et à un
Controller qui exécute l'action (lorsque nous appuyons sur tel ou tel bouton
de telle ou telle page jsp).
5.3 Conclusion
Dans le modèle MVC la séparation Modèle, Controller, Vue est moins stricte que
l’on ne le croit. C’est plus une manière de voir le code.
Comme dit plus haut, l’implémentation présentée ci-dessus part d’un souci
d’ouverture et de facilité de maintenance pour la suite probable de
développement. Nous avons ici fait un gros framework capable d’encadrer les
futures implémentations ou modifications en sachant que le code ne prend pas en
charge toute la réalité de ce que serait l’implémentation totale et fonctionnelle du
serveur central des échanges de données dans le secteur médical. Néanmoins, il
est conçu de sorte à pouvoir accueillir aisément les problématiques plus complexes
de l’implémentation du NHCX ou d’étendre ce qui est déjà fait.
80
Chapitre 6
Conclusion
Les échanges de données dans le secteur médical en Belgique ne sont pas
encore, au moment où nous écrivons ce mémoire, règlementés.
Comme nous l’avons vu précédemment, un mécanisme tente de se mettre en place
et une série d’études sont menées afin de mener à bien ce projet.
L’un des grands problèmes que connaissent actuellement les échanges de dossiers
médicaux informatiques en Belgique est celui d’incompatibilité de logiciels
présents sur le marché.
Le modèle que nous proposons résoudrait ce problème dans la mesure où il est
indépendant du logiciel qu’utilise chaque centre de santé, pourvu que le message
envoyé soit de format XML KMEHR.
Se basant sur les acquis technologiques et techniques informatiques présents
(Système d’authentification propres à chaque centre de santé, KMEHR, et le
thésaurus 3BT), nous avons montré qu’un système décentralisé, avec un serveur
central jouant le rôle de véritable chef d’orchestre des échanges conviendrait
parfaitement aux exigences des échanges de données médicales en Belgique.
Notre implémentation est orientée par le souci de mettre sur pied une
implémentation pouvant réellement accueillir aisément toute fonctionnalité qui
devrait composer le système des échanges de données dans le serveur central. Le
choix du modèle MVC permet de découper en couches « layers » le plus possible
le code et ainsi permettre à une équipe composée de plusieurs compétences
81
(design, base de donnée, J2EE) de travailler ensemble dans le code, chacun sur la
partie qui lui est la plus appropriée.
Nous voyons donc que la réalisation de ce grand projet qui est celui des échanges
de données dans le secteur médical, pose un problème plus éthique et politique,
compte tenu du caractère privé et confidentiel que revêtent les données médicales,
que technique. En effet, comme nous l’avons montré dans ce mémoire, il est
techniquement et technologiquement possible d’implémenter ce grand projet.
82
Annexe
Un cd d’implémentation est disponible à la bibliothèque du département
informatique de l’Université Libre de Bruxelles – Université d’Europe.
83
Bibliographie
[1] O. Caudron. Le DMP Néerlandais. S.E InterSystem 2006
[2] M. Roland, J. De Maeseneer, M. Verbeke, M. De Jonghe, N.
Kacenelenbogen, D. Schrans, S. Deroose, M. Jamoulle. Thesaurus 3BT :
objectifs, structure, enjeux éthiques, historique, études. Avril 2007. Soutien
financier : Ministère de la Santé Publique.
[3] Dr M. De Jonghe, Dr D. Porignon. Rapport de la mission complémentaire
relative à la classification des pathologies au niveau du CHUK, août 2005
[4] ICD-10. International Statistical Classification of Disease and Related Health
Problems. Geneva (Switzerland): World Health Organisation; 1992.
[5] ICPC-2 International Classification of Primary Care, second edition. Prepare by
the International Classification Committee of WONCA. Oxford: Oxford
University Press, 1998.
[6] IM. Okkes, M. Jamoulle, H. Lamberts, N. Bentzen ICPC-2-e. The electronic
version of ICPC-2. Differences with the printed version and the consequences. Fam
Pract 2000;17:101-6.
[7] M. Jamoulle Use in the European Community WONCA International
Classification Committee at the 16th WONCA World Congress of Family Doctors,
Durban, South Africa, May 13th to 17th 2001.
[8] R. Lagasse, M. Desmet, M. Jamoulle, G. Correa, M. Roland, P. Hoyois, Ch.
De Brouwer. European situation of the routine medical data collection and their
utilisation for health monitoring, Euro-Med-Data, Final Report, December
2001.
[9] M. Jamoulle, M. Roland, J. Humbert, JF. Brûlet (Eds). Traitement de
l'information médicale par la Classification Internationale des Soins Primaires
2ème version (CISP-2), assorti d'un glossaire de médecine générale, préparé par le
84
Comité International de Classification de la WONCA, Care Edition,
Bruxelles, 2000.
[10] https://portal.health.fgov.be
[11] Final report – HEPI GO, August 2006
[12] www.health.fgov.be/telematics, rubrique "communication 1ère et 2ème
ligne"
[13] Dr M. Bangels. Normes en matière de Télématique au service du secteur des Soins
de Santé, 2003
[14] R. De Brandt et T. Gravet. Informatique et Télématique des Soins de Santé,
décembre2005
[15] http://fr.wikipedia.org/wiki
[16] S. Ladd, D. Davison, S. Devijver. Expert Spring Mvc And Web Flow (Broché)
[17] J. Dubois, JP. Retaillé, T. Templier. Spring par la pratique : Mieux développer
ses applications Java/J2EE avec Spring, Hibernate, Struts, Ajax (Broché)
