Suivi de patients dans un service hospitalier

**amizd** · 12/05/2020, 17h44

Mon sujet c'est la Suivi de patients dans un service hospitalier , et voici le mcd qui je l'ai fait.
j'espère de vous me donner des remarques et m'aider pour continue le partie qui concerne le pharmacie et merci d'avance

Un malade est identifié par les informations suivantes :
- N° Dossier (créé par le service d'acceuil du patient (N°séquentiel/année en cours)) - Nom et Prénom - Données démographiques (Poids - Taille - Surface corporelle) - la localisation de sa maladie.
Un malade suit un ou plusieurs protocole (une ordonnance). Un protocole est défini par :
- un code médical - les médicaments qu'il contient - les doses de chaque médicament - le nombre de cures qu'il nécessite.
Un médicament peut se retrouver dans plusieurs protocoles.
Une cure est définie par : un code (C+n°séquentiel) - une date
Une cure peut-être décomposée en sous-cures codées chacune (code de la cure + J + n°séquentiel).
Un malade est suivi par un médecin et est affecté à un service.
un malade peut faire une réaction à un médicament qu'il faut reporter dans son dossier.

Suivi de patients dans un service hospitalier
Exemples de protocole :
Un protocole est un schéma de traitement composé de médicaments et leurs posologies, une
durée d'administration de ces médicaments décomposés en cures (décomposées elles-mêmes
en sous-cures) et leur fréquences. Les protocoles ont des noms issus d'une nomenclature
internationale. Les codes des cures (et sous-cures) sont celles utilisées par les pratiquants du
domaine (corps médical...).
Normalement, le nombre de cures est définies à l'avance dans le protocole. Cependant, et
dans certains cas, ce nombre est pris à titre indicatif et peut changer.

Exemple 1 : protocole FalFox 4. Il comprend 4 médicaments, chacun avec sa posologie, et
éventuellement son mode d'administration :
- oxaliplatine 85 mg/m2 : en J1 : 1er jour de la cure
- acide falinique : 200 mg/m2 : en J2 : 2ème jour de la cure
- 5Fluorouracile : 400 mg/m2, mode d'administration : en bolus (administrée au complet d'un
seul coup) : en J1
- 5Fluorouracile : 2400 mg/m2, mode d'administration : 1200 mg/m2 en continu (perfusion de
24h) en J1, 1200 mg/m2 en continu (perfusion de 24h) en J2
Cette cure est répétée chaque 14 jours, 12 fois (12 cures en 6 mois de traitement).
Les cures sont codées C1, C2, ... C12, et les sous-cures J1, J2.

Existant :
Chaque jour, le pharmacien reçoit une ordonnance (qu'il appelle protocole par abus de
langage) qui contient :
- N° Dossier (créé par le service d'accueil du patient (N°séquentiel/année en cours)) -
Nom et Prénom - Données démographiques (Poids - Taille - Surface corporelle (m²) =
0,007184 x Taille(cm)
0,725 x Poids(kg)
0,425 ) - la localisation de sa maladie.

- les médicaments qu'il doit recevoir ce jour, avec pour chaque médicament sa
posologie avec éventuellement une réduction de la dose (ex : posologie de 1000 mg/m2 avec
une réduction de 10% sur la dose à administrer).
Le pharmacien code l'ordonnance par un n°séquentiel + date du jour, enregistre toutes les
informations sur un registre.
En se basant sur ce registre, le pharmacien essaie de valider l'ordonnance en vérifiant que
l'ordonnance prescrite par le médecin respecte le protocole suivi par le patient, et que la
posologie (calculée par le médecin) est correcte.
Cependant, et avec le nombre important des malades, la formule (registre + stylo) est vite
dépassée.
Fonctionnalités souhaitées

Le pharmacien attend du logiciel que vous avez à développer qu'il réalise les fonctionnalités
suivantes :
- Enregistrer un nouveau patient.
- Sélectionner le nom du protocole qu'il suit (cette information n'est pas toujours disponible)
- Etablir un planning des cures à partir de la date de la 1ère cure (date saisie par le
pharmacien)
- Calculer la surface corporelle à partir des données du patient pour les comparer avec celles
du médecin (sur l'ordonnance). (Exemple : Taille du patient = 165 cm, poids = 60 kg == >
Surface corporelle = 1,66 m2 selon la formule Dubois (à vérifier par vos calculettes ou sur
une application de calcul des surfaces corporelles !! )
- Editer les posologies à partir du protocoles pour que le pharmacien puisse les comparer avec
celles données par le médecin, puis calculer les doses à administrer pour chaque médicament
(Exemple : en supposant qu'il y a un seul médicament M1 avec une posologie de 100 mg/m2
=> dose de M1 à administrer = 1,66 m2 * 100 mg/m2 = 166 mg )
- Pour chaque jour, établir la liste des patients attendus, avec la cure ou sous-cure du jour.
(cette fonctionnalité est possible uniquement si le protocole à suivre est connu d'avance. Dans
le cas contraire, on peut proposer au pharmacien de saisir à chaque cure la date de la
prochaine cure)
- Possibilité de consulter à tout moment l'historique du malade (surtout la cure précédente si
elle existe pour voir les doses administrées, s'il y a eu réaction au traitement, s'il y a eu des
réductions, ... etc.).
- Valider l'ordonnance (si tout va bien et si elle a été délivrée par le pharmacien ) :
l'enregistrer (avec son code) dans le dossier du patient en notant les effets secondaires et
autres allergies + les éventuelles réductions faites dans les doses, et autres observations que le
médecin ou le pharmacien désire noter.
- En cas d'absence du malade, un nouveau planning devrait être généré.
- Etablir des statistiques journalières, comme le nombre d'ordonnances traitées, la liste des
patients ayant reçu leurs cures, et la listes des patients qui ne l'ont pas reçu (pour raison
d'absence ou autre).
Remarque importante : La médecine n'étant pas une science exacte, il y a une différence entre
ce qui devrait être fait et ce qui est réellement fait (un protocole théorique et un protocole
réel).
Nom : MCDEA.PNG
Affichages : 2110
Taille : 79,5 Ko

Nom : MCDEA.PNG
Affichages : 2110
Taille : 79,5 Ko

**escartefigue** · 14/05/2020, 18h36

Bonsoir Amizd

Quelques remarques

D'une façon générale, quand les règles de gestion stipulent "peut ou peuvent" c'est que l'association est facultative.

Ainsi

Envoyé par amizd

Un malade suit un ou plusieurs protocole

Signifie que tout malade suit à minima un protocole. Ce qui me surprend du reste, car il m'est souvent arrivé d'aller chez le médecin sans en sortir avec une ordonnance, mais admettons.

Alors que

Envoyé par amizd

Une cure peut-être décomposée en sous-cures codées chacune (code de la cure + J + n°séquentiel).

Signifie que toute cure n'a pas obligatoirement une sous-cure

Et il faut bien tenir compte de ces différences sémantiques dans leur transcription au niveau des cardinalités minimales : la première règle implique une cardinalité minimale de un alors que la deuxième implique zéro.
Ce que vous n'avez pas fait dans votre schéma, à corriger sur les différentes associations concernées

Attention : l'énoncé comporte des pièges (c'est la loi du genre ), par exemple

Envoyé par amizd

Un malade est identifié par les informations suivantes :
- N° Dossier (créé par le service d'acceuil du patient (N°séquentiel/année en cours)) - Nom et Prénom - Données démographiques (Poids - Taille - Surface corporelle) - la localisation de sa maladie.

Ne signifie pas que toutes les informations ci-dessus sont des attributs du patient
Par exemple, la localisation de la maladie n'est évidemment pas un attribut du malade : un patient peut venir plusieurs fois pour des affections éventuellement différentes et éventuellement localisées à différents endroits.
Il faut donc en tenir compte dans votre modèle
Concernant le poids, la taille et autres mesures effectuées sur le patient, ça peut éventuellement être un attribut du patient si on ne s'intéresse pas à l'historique, dans la négative, il s'agit d'attributs liés à la consultation d'un patient, les valeurs pouvant changer d'une fois sur l'autre (ne serait-ce que si le patient est un enfant

)
Note : le terme "malade" est inadéquat sauf si ce service hospitalier ne reçoit que des malades avérés, sinon certains patients consultent un médecin sans pour autant être malades, cas d'espèce : le certificat médical requis pour le sport (on fait rarement son certificat médical à l'hopital, mais il y a sans doute d'autres exemples applicables dans votre contexte, à vérifier)

Attention aux associations "mille-pattes"

Je ne sais pas ce que vous avez voulu représenter avec l'association "Asso 5", mais, d'une façon générale, les associations à plus de deux "pattes" méritent réflexion.
Les ternaires valides restent relativement fréquentes, au delà, il est très rare qu'on ne soit pas dans le cas d'une erreur de modélisation.
À argumenter donc (quelles sont les règles de gestion de l'énoncé qui vous ont conduit à cette association ?)

de la même façon "Asso 7", est suspecte ainsi que l'entité-type "injecter" qui intervient dans cette asso : quelles sont les règles de gestion issues de l'énoncé qui ont conduit à cette schématisation
À préciser

Voila en première approche très rapide

EDIT je n'y avais pas prêté attention mais une association ne peut pas être en relation avec une autre associaton !
Ainsi "Asso8" en lien avec "Asso5" est invalide, je suis d'ailleurs surpris que vous aillez réussi à piéger Looping sur ce point.
Paprick Heeeelp !, y aurait-il une faille sur les liens d'associations ? En tout cas je n'arrive pas à reproduire ce bug !

**Paprick** · 15/05/2020, 02h05

Bonsoir Capitaine,

Envoyé par escartefigue

EDIT je n'y avais pas prêté attention mais une association ne peut pas être en relation avec une autre associaton !
Ainsi "Asso8" en lien avec "Asso5" est invalide, je suis d'ailleurs surpris que vous aillez réussi à piéger Looping sur ce point.
Paprick Heeeelp !, y aurait-il une faille sur les liens d'associations ? En tout cas je n'arrive pas à reproduire ce bug !

Rassure-toi, il n'y a pas de faille !

En fait, "Asso8" n'est pas en lien avec "Asso5" : le lien passe sous Asso5 pour rejoindre "patient" !

(et "Asso5" n'est donc pas une quaternaire

...)

Ce qui m'amène à la remarque générale suivante : la présentation du modèle est un aspect non négligeable pour sa bonne compréhension.
Donc, Amizd, il va falloir mettre un peu d'ordre dans tout ça !

Enfin, sans rentrer dans le détail de la conception, je confirme les craintes émises quant à l'utilisation d'associations n-aires... Elles doivent être utilisées avec moultes précautions, ne dépassent quasiment jamais 3, et nécessitent presque toujours la mise en place de contraintes d'intégrité fonctionnelle (CIF) pour garantir l'irréductibilité des identifiants (respect clés minimales).
Bref, même si je n'ai jeté qu'un rapide coup d'œil, dans votre modèle, elles ne me paraissent pas forcément justifiées.

A suivre...

**escartefigue** · 15/05/2020, 11h21

Envoyé par Paprick

En fait, "Asso8" n'est pas en lien avec "Asso5" : le lien passe sous Asso5 pour rejoindre "patient" !

(et "Asso5" n'est donc pas une quaternaire

...)

Bon sang mais c'est bien sûr !

Envoyé par Paprick

Ce qui m'amène à la remarque générale suivante : la présentation du modèle est un aspect non négligeable pour sa bonne compréhension.
Donc, Amizd, il va falloir mettre un peu d'ordre dans tout ça !

+1 !

**amizd** · 15/05/2020, 16h28

merci pour vous precedentes remarques ,
et ceci le modele apres la correction de quelques erreur
j'aimerias bien de le voir et me donner des remarques

Nom : MCDEA2.PNG
Affichages : 1585
Taille : 65,5 Ko

**escartefigue** · 15/05/2020, 20h06

Envoyé par amizd

Une cure peut-être décomposée en sous-cures codées chacune (code de la cure + J + n°séquentiel). [...]
Exemples de protocole :
Un protocole est un schéma de traitement composé de médicaments et leurs posologies, une durée d'administration de ces médicaments décomposés en cures (décomposées elles-mêmes en sous-cures) et leur fréquences.

Ces deux extraits sont contradictoires, le premier indique clairement que la sous-cure est facultative, le deuxième tend à indiquer le contraire...
Selon le cas, il faut une association entre le médicament et la cure.

Envoyé par amizd

Un malade est suivi par un médecin et est affecté à un service.
un malade peut faire une réaction à un médicament qu'il faut reporter dans son dossier.
[...]
Chaque jour, le pharmacien reçoit une ordonnance (qu'il appelle protocole par abus de langage) qui contient

Ces parties ne sont pas schématisées dans votre nouveau modèle

Envoyé par amizd

Le pharmacien attend du logiciel que vous avez à développer qu'il réalise les fonctionnalités
suivantes [...]

Toute cette partie qui concerne le pharmacien présente peu d'intérêt pour la modélisation des données mais sera utile pour modéliser les traitements.
Il y a toutefois quelques informations à retenir. Par exemple, on y apprend que la surface corporelle est une donnée calculée à partir de la taille et du poids.
Par conséquence, il ne faut pas la stocker, ce serait une redondance.
Cet extrait parle également de la sous-cure comme d'une option.
Il y est également question de planning, la gestion des plannings est un projet en soi, je ne pense pas que votre exercice doive prendre en compte cet aspect, à vérifier.
On y apprend aussi que le protocole appliqué par le pharmacien peut être différent de celui préconisé par le médecin, il faudra en tenir compte quand vous modéliserez cette partie de l'énoncé.

Point important : en l'état, votre MCD autorise un patient à subir des effets secondaires de médicaments qu'il n'a pourtant pas pris

Il est nécessaire de positionner des "Contraintes d'Intégrité Fonctionnelles" (CIF pour les intimes) pour éviter ce genre de mésaventure.
Nous y reviendrons plus tard

Pour finir, votre MCD est un peu plus clair, mais il reste des croisement de "pattes" d'associations qui nuisent à la lisibilité.
Pour éviter ces croisements utilisez l'outil "cassure" de looping avec lequel vous pouvez choisir le trajet de chaque patte :
vous cliquez sur la "patte", puis sur l'outil "cassure" et à nouveau sur la patte (on voit apparaître une poignée sur cette patte, permettant de créer des angles), puis à nouveau sur l'outil "sélection" pour modifier le trajet de cette patte.

**fsmrel** · 16/05/2020, 04h46

Bonsoir,

A amizd :

Question Q1 : à une date donnée, un patient peut-il suivre plus d’un protocole ?

Association TRAITER :

Variation sur un thème évoqué par le Capitaine Escartefigue : selon l’association TRAITER, un patient peut être traité avec un médicament qui ne fait pas partie de ses protocoles. Question Q2 : Est-ce possible ?

Pour un patient et un médicament donnés, selon l’association TRAITER, on a au moins et au plus un effet secondaire. Question Q3 : Est-ce vraiment ce que vous cherchez à modéliser ?

Selon l’association ASSO8, on ne connaît les effet secondaires d’un médicament qu’à la condition qu’un patient soit partie prenante dans cette association. En l’absence de patient prenant tel médicament, impossible de connaître les effets secondaires d’icelui. Cela paraît bien réducteur. Question Q4 : n’est-il pas légitime de savoir quels sont les effets secondaires connus d’un médicament, avant de l’administrer à des patients ?

Les effets secondaires interviennent dans les deux associations TRAITER et ASSO8 : il y a une redondance de l’information, donc une maladresse dans la modélisation.

Le MCD est manifestement un peu souffrant, il va falloir qu’on le soigne...

**escartefigue** · 16/05/2020, 11h22

Il faut distinguer les effets indésirables que peuvent produire les médicaments des effets indésirables effectivement subis par les patients.
Ce sont deux associations distinctes.

On devrait donc avoir quelque chose du type :

Pièce jointe 565929

Le cercle marqué (I) est la CIF d'inclusion correspondant à la règle de gestion que j'ai identifiée arbitrairement RG010 et qui stipule qu'un patient ne peut subir des effets indésirables que s'il prend le médicament susceptible de produire cet effet indésirable.
Je trouve pratique de numéroter les règles de gestion, c'est plus facile pour en discuter que de devoir en citer le libellé in extenso à chaque fois.
Looping permet, grâce à l'outil règle, de décrire et nommer une règle, mais aussi d'y associer un script SQL. C'est ce que j'ai fait un créant une contrainte de type REFERENCE qui permettra de vérifier cette règle RG010

.
J'ai choisi de ne pas afficher le script SQL dans le modèle, mais c'est possible au moyen d'une simple case à cocher.

Notez au passage l'utilisation de l'outil "cassure" qui m'a permis d'éviter les croisements à la fois du lien PA_patent vers SV_suivre mais aussi pour la flèche qui va de la règle RG010 vers la CIF d'inclusion

J'ai ajouté une table de typologie permettant de typer les effets indésirables (type respiratoire, cutané, cardiaque...)

Le type d'entité CA_CALENDRIER me permet de faire participer la date aux associations PR_prendre et SV_suivre. En effet, un même patient doit pouvoir prendre un même médicament ou suivre un même protocole à plusieurs reprises. On ne génèrera pas la table CA_calendrier qui serait inutile, mais les tables issues des associations PR_prendre et SV_suivre auront la colonne CA_date incluse dans leur PK, ce qui permettra de suivre un protocole plusieurs fois ou de prendre un médicament plusieurs fois

.

Les associations PR_prendre et SU_subir sont porteuse d'une date de fin (une durée en jours aurait sans doute été préférable d'ailleurs) pour connaître la durée d'un effet indésirable ou de la prise d'un médicament.

Voici le script proposé par Looping (j'ai opté pour SQL Server) avec, tout en bas, la contrainte saisie dans la règle RG010 et ajoutée par Looping dans le script

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
CREATE TABLE MC_medicament(
   MC_ident INT IDENTITY,
   MC_num_agrement CHAR(15) NOT NULL UNIQUE,
   MC_nom VARCHAR(50) NOT NULL,
   PRIMARY KEY(MC_ident)
);
 
CREATE TABLE PA_patient(
   PA_ident INT IDENTITY,
   PA_nom VARCHAR(50) NOT NULL,
   PA_prenom VARCHAR(50) NOT NULL,
   PA_ddn DATE NOT NULL,
   PRIMARY KEY(PA_ident)
);
 
CREATE TABLE YE_type_effet(
   YE_ident INT IDENTITY,
   YE_code CHAR(5) NOT NULL UNIQUE,
   YE_libelle VARCHAR(50) NOT NULL,
   PRIMARY KEY(YE_ident)
);
 
CREATE TABLE PO_protocole(
   PO_ident INT IDENTITY,
   PO_code CHAR(4) NOT NULL UNIQUE,
   PO_nom VARCHAR(50) NOT NULL,
   PRIMARY KEY(PO_ident)
);
 
CREATE TABLE EI_effet_indes(
   MC_ident INT,
   EI_ident INT IDENTITY,
   EI_descritption VARCHAR(255),
   YE_ident INT NOT NULL,
   PRIMARY KEY(MC_ident, EI_ident),
   FOREIGN KEY(MC_ident) REFERENCES MC_medicament(MC_ident),
   FOREIGN KEY(YE_ident) REFERENCES YE_type_effet(YE_ident)
);
 
CREATE TABLE SU_subir(
   PA_ident INT,
   MC_ident INT,
   EI_ident INT,
   SU_dtdeb DATE NOT NULL,
   PRIMARY KEY(PA_ident, MC_ident, EI_ident),
   FOREIGN KEY(PA_ident) REFERENCES PA_patient(PA_ident),
   FOREIGN KEY(MC_ident, EI_ident) REFERENCES EI_effet_indes(MC_ident, EI_ident)
);
 
CREATE TABLE PR_prendre(
   MC_ident INT,
   PA_ident INT,
   CA_date DATE,
   PR_dtfin DATE NOT NULL,
   PRIMARY KEY(MC_ident, PA_ident, CA_date),
   FOREIGN KEY(MC_ident) REFERENCES MC_medicament(MC_ident),
   FOREIGN KEY(PA_ident) REFERENCES PA_patient(PA_ident),
   FOREIGN KEY(CA_date) REFERENCES CA_calendrier(CA_date)
);
 
CREATE TABLE SV_suivre(
   PA_ident INT,
   CA_date DATE,
   PO_ident INT,
   SV_dtfin DATE NOT NULL,
   PRIMARY KEY(PA_ident, CA_date, PO_ident),
   FOREIGN KEY(PA_ident) REFERENCES PA_patient(PA_ident),
   FOREIGN KEY(CA_date) REFERENCES CA_calendrier(CA_date),
   FOREIGN KEY(PO_ident) REFERENCES PO_protocole(PO_ident)
);
 
CREATE TABLE CO_concerner(
   MC_ident INT,
   PO_ident INT,
   PRIMARY KEY(MC_ident, PO_ident),
   FOREIGN KEY(MC_ident) REFERENCES MC_medicament(MC_ident),
   FOREIGN KEY(PO_ident) REFERENCES PO_protocole(PO_ident)
);
 
ALTER TABLE U_subir
   ADD CONSTRAINT FK01_SUPR
   FOREIGN KEY (PA_ident, MC_ident) REFERENCES PR_prend

Attention : on ne pourra pas par simple contrainte vérifier qu'un effet indésirable ne serait pas subi avant même d'avoir pris le médicament. Ce type de contrôle pourra être fait par un trigger.

Si un patient ne peut pas suivre plusieurs protocoles simultanément, il faudra évacuer l'identifiant de protocole de la PK de la table SV_suivre (ce qui constituera un contrôle à minima car ça n'interdira pas un chevauchement de période entre deux protocoles)

EDIT : en relisant, je vois que j'ai oublié d'appliquer la même logique pour l'association SU_subir que pour PR_prendre et SV_suivre.
Comme un même patient peut subir à plusieurs reprises le même effet indésirable, il faut faire contribuer la date à la PK de la table issue de cette association.
Donc soit on tire une "patte" de cette association vers CA_calendrier et on retire l'attribut SU_dtdeb de l'association (car il devient redondant)
Soit on conserve l'attribut SU_dtdeb dans l'association et on modifie le script SQL pour faire participer cet attribut à la PK

**Paprick** · 16/05/2020, 19h49

Bonsoir,

Envoyé par escartefigue

Le type d'entité CA_CALENDRIER me permet de faire participer la date aux associations PR_prendre et SV_suivre. En effet, un même patient doit pouvoir prendre un même médicament ou suivre un même protocole à plusieurs reprises. On ne génèrera pas la table CA_calendrier qui serait inutile, mais les tables issues des associations PR_prendre et SV_suivre auront la colonne CA_date incluse dans leur PK, ce qui permettra de suivre un protocole plusieurs fois ou de prendre un médicament plusieurs fois

.

Voici le script proposé par Looping (j'ai opté pour SQL Server) avec, tout en bas, la contrainte saisie dans la règle RG010 et ajoutée par Looping dans le script

CREATE TABLE PR_prendre(
MC_ident INT,
PA_ident INT,
CA_date DATE,
PR_dtfin DATE NOT NULL,
PRIMARY KEY(MC_ident, PA_ident, CA_date),
FOREIGN KEY(MC_ident) REFERENCES MC_medicament(MC_ident),
FOREIGN KEY(PA_ident) REFERENCES PA_patient(PA_ident),
FOREIGN KEY(CA_date) REFERENCES CA_calendrier(CA_date)
);

CREATE TABLE SV_suivre(
PA_ident INT,
CA_date DATE,
PO_ident INT,
SV_dtfin DATE NOT NULL,
PRIMARY KEY(PA_ident, CA_date, PO_ident),
FOREIGN KEY(PA_ident) REFERENCES PA_patient(PA_ident),
FOREIGN KEY(CA_date) REFERENCES CA_calendrier(CA_date),
FOREIGN KEY(PO_ident) REFERENCES PO_protocole(PO_ident)
);

Attention : si tu retires la table CA_calendrier, tu ne peux pas y faire référence dans les autres tables.
Mais , rassure-toi Looping gère très ce type de situation

!!!
En fait, comme CA_calendrier n'a qu'une seule rubrique (et qu'elle joue le rôle d'identifiant), une option "Classe fictive" est proposée. Le nom de la classe d'entités apparaîtra alors entre parenthèses, la table ne sera pas générée et l'attribut CA_date sera automatiquement repris dans les tables associées, et tout cela sans aucune référence à CA_calendrier.
Cette solution est très souvent utilisée pour ce type de modélisation incluant une gestion d'historique.