3.1. La structure des données ... 79 3.2. Les variables du langage LAESH associées à la représentation graphique ... 80
1. Introduction
Pour formaliser l’ensemble de la connaissance des systèmes étudiés à l’aide de modèles permettant de communiquer avec les équipes médicales et paramédicales, nous avons proposé un nouveau langage que nous présentons dans ce cinquième chapitre. Le Langage d’Analyse et d’Étude des Systèmes Hospitaliers (LAESH) reprend les éléments de base du Langage d’Aide à l’Évaluation des Systèmes (LAES) proposé il y a quelques années par le LIMOS pour modéliser les systèmes complexes (Gourgand, 1984; Chabrol, 1986; Chabrol and Gourgand, 1991). Un des avantages de ce langage est sa simplicité qui a facilité la communication avec les hospitaliers, et sa souplesse qui nous a permis d’envisager plusieurs extensions pour l’adapter au mieux au domaine étudié et permettre un passage plus facile de la formalisation de la connaissance à la conception d’outils d’aide à la décision.
Nous décomposons LAESH en deux parties :
- La représentation graphique pour les parcours patient qui représente un outil de communication majeur avec les équipes médicales et paramédicales ;
- Le langage LAESH qui permet, à partir de l’approche graphique, de construire une structure de données du système étudié, à l’aide des codes LAESH.
Nous présentons dans une première section la représentation graphique de LAESH en donnant les concepts de bases, éléments graphiques et symboles de structuration de ce langage avant de présenter les extensions apportées pour l’étude des systèmes hospitaliers. Dans une deuxième section, nous présentons brièvement le langage de description et les variables rattachées à la représentation graphique.
2. La représentation graphique
2.1. Les concepts de base de LAESH : la catégorie, la phase et le chemin
La modélisation avec LAESH s’opère à deux niveaux : le premier niveau, dit « global », utilise les notions de catégorie, de phase et de chemin, et le second niveau, dit « détaillé », donne le contenu de chaque phase. Les systèmes étudiés sont supposés ouverts.
Pour la classe des systèmes étudiés, plusieurs demandes de service sont acceptées concurremment. Une demande de service correspond à une catégorie de « clients » demandant un ensemble d’opérations (ou de services) élémentaires. Avec LAESH, nous considérons que les clients sont les patients. Nous utilisons ensuite la notion de classes de clients pour distinguer :
Classe 1 : classe principale correspondant au patient. L’opération s’exécute directement sur le patient (exemple : acte chirurgical).
Classe 2 : classe correspondant aux tâches annexes qui dépendent et qui sont liées au patient (exemple : rédaction compte rendu opératoire) ;
Classe 3 : classe correspondant aux tâches annexes qui dépendent du patient mais qui sont liées à la structure (exemple : décontamination du matériel).
Le cheminement des patients de chaque catégorie est représenté de façon déterministe. Par abus de langage nous confondons catégorie, catégorie de patients et patient.
Dans le traitement d’une demande, différentes situations peuvent intervenir : demande insatisfaite, traitement complet,… Par définition à chacun de ces cas correspond un chemin. Un
Chapitre 4. Proposition d’un Langage d’Analyse et d’Étude des Systèmes Hospitaliers P a g e| 73 Ch ap itre 4 . Pro po sitio n d ’u n L an ga ge d ’A na lys e et d’É tud e d es S ystème s Ho spit alie rs
élémentaires. Une opération élémentaire représente le découpage le plus fin de l ’activité, et correspond donc à un traitement élémentaire tel qu’il est défini dans la décomposition systémique du domaine. Une phase peut être commune à plusieurs chemins.
Ces notions de phase et de chemin paraissent naturelles pour les systèmes étudiés. En effet, deux demandes identiques n’ont pas la même probabilité d’aboutir. Par contre ces notions ne sont pas rigides puisque pour un même système le niveau de modélisation choisi peut être plus ou moins fin. La sortie d’une phase correspond en général à la réalisation d’une condition (par exemple présence ou absence de la ressource demandée, événement externe, fin de traitement,…) et l’entrée dans une phase correspond à la réalisation d’un événement (par exemple arrivée d’un patient, allocation d’une ressource,…). Dans le cas de la demande d’une ressource, deux cas peuvent se produire : la ressource est ou n’est pas disponible. Il y a donc une sortie (c’est à dire fin) de la phase de demande et entrée dans la phase d’allocation ou dans la phase correspondant à l’absence de ressource et dans les deux cas poursuite du traitement. Le passage d ’une phase à une autre peut se faire selon une probabilité définie (PR(I,J,K) : probabilité de transition de la phase I à la phase J dans la catégorie K).
Pour ce qui est des ressources, LAESH distingue deux types de ressources :
les ressources actives, que nous assimilons aux ressources humaines et qui sont associées à chaque opération élémentaire ;
les ressources passives qui représentent les ressources matérielles et qui sont associées à une ou plusieurs opération(s) élémentaire(s).
La Figure 4-1 donne un exemple de représentation globale d’une catégorie de patient contenant cinq phases et trois chemins, ainsi que l’exemple de la représentation détaillée d’une phase. Chaque phase fait l’objet d’une représentation graphique détaillée qui fait apparaître l’enchaînement des opérations élémentaires. La Figure 4-1 donne un aperçu de l’enchaînement des deux premières opérations d’une phase. Les opérations mobilisent des ressources passives et des ressources actives.
Dans le langage initialement créé, l’exécution d’une opération élémentaire par une ressource active se représente par :
où :
i est le numéro ou le nom de la ressource active ;
t est le temps de l’opération élémentaire ;
c la classe du client servi ;
n le nombre d’exécutions ;
b le bit de mise en file d’attente qui vaut 1 s’il y a mise en file d’attente, 0 sinon ;
c, n et b peuvent être omis s’ils valent 1.
Avec LAESH, nous avons remplacé cette liste d’attributs par celle des attributs rattachés à l’opération élémentaire (classe traitement élémentaire de la décomposition systémique donnée dans le sixième chapitre).
Au vu de ces premiers éléments, nous donnons la table de correspondance entre les principaux concepts de base de LAESH et la décomposition systémique réalisée à l’aide de diagrammes de classes UML (Tableau 4-1).
Classe UML Élément LAESH
Parcours Catégorie
Activité Phase
Traitement élémentaire Opération élémentaire Temporisation
Ressource humaine Ressource active Ressource matérielle Ressource passive
Tableau 4-1. Correspondances des principaux éléments UML et LAESH
2.2. Les éléments graphiques et symboles de structuration de base
LAESH
Chaque phase des représentations graphiques globales fait l’objet d’une représentation graphique détaillée. Celle-ci fait apparaître l’enchaînement des opérations élémentaires et des symboles de structuration :
Début et fin de phase : le début d’une phase est indiqué par le numéro de la phase
précédente ou l’extérieur (EXT). La fin d’une phase est indiquée par le numéro des phases suivantes ou l’extérieur. Le symbole graphique qui suit le début d’une phase ou qui précède la fin d’une phase est le symbole d’une opération élémentaire ou d’une structuration.
Exécution d’une opération élémentaire : l’exécution d’une opération élémentaire est
Chapitre 4. Proposition d’un Langage d’Analyse et d’Étude des Systèmes Hospitaliers P a g e| 75 Ch ap itre 4 . Pro po sitio n d ’u n L an ga ge d ’A na lys e et d’É tud e d es S ystème s Ho spit alie rs
passives. La combinaison de ressources nécessaires et la liste des attributs propres à l’opération élémentaire (temps, priorité…) sont données.
Temporisation : une temporisation représente un temps d’attente avant de poursuivre le
parcours patient. Elle correspond donc à un traitement élémentaire ne mobilisant pas de ressources humaines ;
Prise et rendu de ressource passive : la prise et le rendu d’une ressource passive sont
obligatoirement effectués par une ressource active. Les ressources actives effectuant la prise et le rendu peuvent être différentes. Une prise de ressource passive dans une phase implique le rendu de cette même ressource dans tous les chemins contenant la phase de la prise. La prise et le(s) rendu(s) d’une ressource passive sont identifiés à l’aide d’un indicateur.
Boucle : les règles de structure applicables aux boucles sont celles appliquées en
algorithmique (l’imbrication de boucles est autorisée mais le chevauchement des boucles est interdit).
Traitement en parallèle : les traitements en parallèles utilisent les notions de nœuds et
de branches. Le calcul des temps se fait en prenant pour chaque nœud le plus grand des temps des branches du nœud.
Appel de phase : dans la description d’une phase on peut retrouver le contenu d’une
autre phase. Plutôt que de reproduire ce contenu, on peut utiliser le symbole d ’appel de phase. La représentation graphique reprend le numéro de la phase appelée ainsi qu’une liste de paramètres. La liste est vide si le contenu de la phase i doit être repris dans son intégralité. La possibilité de paramétrer une description de phase et un appel de phase permet, lors d’un appel, de remplacer les paramètres de la phase (paramètres formels) par les valeurs des paramètres d’appel (paramètres effectifs). L’appel de phase n’est autorisé que dans la catégorie de description de la phase.
Appel de sous phase : dans la description d’une ou plusieurs phases on peut trouver des
sous-ensembles identiques. Plutôt que de reproduire ce sous-ensemble on peut le définir comme étant une sous phase et utiliser le symbole d’appel de sous phase. Comme pour l’appel de phase, la représentation graphique reprend le numéro de la sous-phase appelée ainsi qu’une liste de paramètres (si différents de la phase d’origine). L’appel de sous-phase est autorisé dans toutes les catégories du système.
Déclenchement de catégorie : une catégorie de patient peut être déclenchée (créée) à la
suite d’une opération élémentaire ou d’une temporisation. La représentation graphique donne le numéro de catégorie déclenchée, le nombre d’instances de cette catégorie déclenché ainsi qu’un éventuel délai entre la fin de l’opération élémentaire ou de la temporisation déclenchant la catégorie et sa création effective.
Le Tableau 4-2 donne les représentations graphiques de ces différents éléments avec le code LAESH correspondant.
2.3. Les extensions apportées pour l’étude des systèmes hospitaliers
Nous avons apporté plusieurs extensions au langage LAESH pour prendre en compte les problématiques rencontrées dans les systèmes hospitaliers.
Description Code LAESH Représentation graphique
Début de Phase DEPH
MG, Tps3 ,1, Zone2 ... i
Fin de Phase FIPH
EXT j
SF, Tps1 ,1, Zone1 ...
Opération élémentaire EXEC EXEC, <liste>
Temporisation TEMP TEMP, <liste> ...
Prise de ressource passive DEPR
EXEC, <liste> RP, <liste>
Rendu de ressource passive FIPR RP, <liste> EXEC, <liste>
Début de Boucle Fin de Boucle
DEBO
FIBO N EXEC, <liste> Début de Traitement en parallèle
Fin de Traitement en parallèle
DEPA
FIPA EXEC, <liste> EXEC, <liste>
//
Appel de Phase APPH I, <liste>
Appel de Sous-Phase APSP J, <liste>
Déclenchement de catégorie DECA EXEC, <liste>
DECA, <liste>
Chapitre 4. Proposition d’un Langage d’Analyse et d’Étude des Systèmes Hospitaliers P a g e| 77 Ch ap itre 4 . Pro po sitio n d ’u n L an ga ge d ’A na lys e et d’É tud e d es S ystème s Ho spit alie rs
2.3.1. Multiplication des chemins à chaque XOR pour une opération
élémentaire mobilisant les mêmes ressources
Le cheminement des patients comprend de nombreuses étapes où l’on peut avoir le choix entre deux opérations (« ou exclusif » = XOR) mobilisant les mêmes ressources actives et passives. On peut avoir plusieurs enchaînements d’opérations de ce type dans un même parcours. Dans le langage initialement créé, chaque XOR se traduisait par la création de nouveaux chemins, entraînant ainsi une multiplication des parcours. L’exemple est donné par la Figure 4-2.
Figure 4-2. Traduction d’un ensemble d’enchaînements de conditions XOR en LAES
Avec LAESH, nous proposons de traduire l’ensemble des enchaînements XOR par une seule opération dont le temps d’exécution prendra en compte l’ensemble des possibilités. La Figure 4-3 illustre la solution proposée :
Figure 4-3. Extension LAESH proposée pour éviter la multiplication des chemins
pi représente la probabilité que l’activité i soit réalisée et que l’activité i’ soit non réalisée. Lorsque qu’une opération peut être ou ne pas être effectuée, il s’agit d’un cas particulier où t’i est nul.
2.3.2. Mobilisation ponctuelle et cyclique des ressources actives par une
opération élémentaire longue à durée variable
Certaines opérations mobilisent la ou les ressource(s) passive(s) pendant tout le temps T mais ne mobilisent la ou les ressource(s) active(s) que ponctuellement. Les ressources actives doivent donc pouvoir être libérées pour effectuer simultanément d’autres opérations. Nous proposons dans LAESH de placer une temporisation de temps t’ après l’exécution de l’opération suivi d’une boucle qui permet de recommencer l’opération et la temporisation NB fois. NB pourra être une constante ou une variable, de même que t’ (Figure 4-4).
Figure 4-4. Mobilisation ponctuelle et cyclique représentée avec LAESH
2.3.3. Utilisation de plusieurs ressources sur une opération élémentaire
Dans le langage initialement créé, à chaque opération élémentaire est associée une ressource active effectuant cette opération. Comme nous l’avons vu en introduction de cette troisième section, les activités réalisées dans les systèmes hospitaliers peuvent faire appel à de nombreuses ressources humaines pour une même opération élémentaire.
Avec LAESH, nous avons introduit la notion « d’équipe » pour réaliser une opération élémentaire. Pour la composition de ces équipes de ressources, les opérateurs « Et » (AND), « Ou logique » (OR) et « Ou exclusif » (XOR) sont utilisés et peuvent être respectivement remplacés par les symboles ,, . Le « Ou logique » se traduit de la façon suivante : si une opération fait appel à l’équipe « RA1 RA2 », alors l’activité pourra être réalisée par ordre de priorité par une des trois équipes, selon la disponibilité des ressources actives :
RA1RA2 RA1 RA2
Grâce à cette extension, si nous reprenons l’exemple de l’activité de césarienne spécifié en réseau de Petri dans le chapitre 1 (section 2, Figure 3-2, p. 50), la combinaison des ressources humaines peut être simplement spécifiée avec LAESH sous la forme :
(RA1 RA2 RA3RA4)RA5 RA6)
Nous avons également instauré cette extension pour les ressources passives.
2.3.4. Utilisation simultanée d’une ressource par plusieurs patients
Certaines opérations ne mobilisent une ressource active que ponctuellement car celle -ci est partagée par plusieurs opérations simultanées portant sur plusieurs patients. De la même façon, une ressource passive peut être partagée par plusieurs patients (par exemple, une salle d ’attente). Avec LAESH, nous choisissons de définir un nouvel attribut de partage des ressources. Cette attribut, noté P(N) se situe juste après la spécification de la ressource ou de la combinaison de ressources. On renseigne (N) si le nombre de patients pouvant mobiliser la ressource est limité. Par défaut une ressource n’est pas partagée.
2.3.5. Maintien d’une même ressource active pour l’enchaînement de
plusieurs opérations : ressources personnalisées
Certaines opérations mobilisent le même type de ressource active et il faut par défaut et sauf indication contraire ou préemption que la ressource active qui enchaîne l’ensemble des opérations jusqu’à la fin du chemin soit la même. Cette notion de « ressource personnalisée » est particulièrement importante dans les systèmes hospitaliers. Avec LAESH, la ressource de type i utilisée est la même pour les opérations élémentaires qui s’enchaînent sur un même parcours, sauf indication contraire ou préemption.
Chapitre 4. Proposition d’un Langage d’Analyse et d’Étude des Systèmes Hospitaliers P a g e| 79 Ch ap itre 4 . Pr op ositio n d ’u n L an ga ge d ’A na lys e et d’É tud e d es S ystème s Ho spit alie rs
2.3.6. Attributs rattachés à chaque opération élémentaire et temporisation
Comme nous l’avons vu, avec LAESH nous remplaçons les attributs initiaux par la liste des attributs rattachés à l’opération élémentaire grâce à l’identifiant « Identifiant traitement ». Cette liste est composée de l’ensemble des attributs de la classe UML « Traitement élémentaire » défini dans le sous-système physique lors de la décomposition systémique en trois sous systèmes du sixième chapitre. Nous faisons la même chose pour les attributs de la temporisation.
3. Le langage LAESH
Un langage de description est utilisé pour la construction d’une structure de données à partir de la représentation graphique. Des modifications ont été apportées au code du langage LAES afin de tenir compte des extensions de LAESH (Chabrol, Gourgand, and Rodier, 2008d). A terme, l’objectif de la structure de données est de permettre une traduction automatique des modèles LAESH vers des outils d’évaluation de la performance.
3.1. La structure des données
La structure des données est organisée en blocs (Figure 4-5) :
Le bloc 1 donne les caractéristiques générales des ressources retenues, le nombre de catégories et le nombre de classes par catégorie.
Le bloc 2 décrit les catégories, les chemins et les phases, (ce bloc correspond à la représentation graphique globale).
Le bloc 3 définit les variables simples et indicées apparaissant dans le fichier.
Les blocs 4,..., N + 3 (N étant le nombre de catégories) correspondent à la représentation graphique détaillée. Le bloc I + 3 (I = 1, ..., N) est relatif à la catégorie I et contient la description des phases de cette catégorie.
Le bloc N + 4 contient les descriptions détaillées des sous-phases pouvant être appelées dans les phases décrites précédemment.
Chaque bloc est défini comme étant un ensemble de phrases et le format général d’une phrase est le suivant :
NUMERO DE PHASE, CODE, RUBRIQUES ; COMMENTAIRE
Une phrase est identifiée par un code. Nous donnons en Annexe I, les codes et les rubriques associées à chaque code.
Ressources, Catégories, Classes
Bloc 1 Clients, Chemins, Phases Bloc 2
Variables Bloc 3
Catégorie 1 Bloc 4
…..
Catégorie N Bloc N + 3
Sous-phases Bloc N + 4
La notion de code doit être introduite pour prendre en compte chacun des problèmes suivants :
traduire une opération (exécution d’un travail par une ressource active, temporisation,…) ;
délimiter un ensemble d’opérations (dans ce cas, il peut être associé à un autre code : c’est par exemple le cas d’un début de phase et d’une fin de phase) ;
définir une ressource, un chemin, une phase, une catégorie ;
définir une variable.
Les rubriques sont séparées par des virgules. Une rubrique peut être une constante, un nom de variable ou être omise. Dans ce cas, la valeur correspondante est soit prise par défaut, soit définie par ailleurs (dans le bloc 3 ou dans un programme exploitant le fichier).
Les rubriques des opérations élémentaires et des délimiteurs peuvent être des variables. En effet, on doit pouvoir facilement et rapidement prendre en compte des modifications sur la structure et/ou le fonctionnement du système à étudier.
Le problème qui se pose alors au niveau de la réalisation est celui du choix des variables, de leur type (variable simple ou variable indicée). Il est clair que des variables simples sont plus faciles à gérer à la fois par l’utilisateur et pour la réalisation du logiciel que des variables indicées. Nous proposons donc que les variables simples puissent être définies librement par l ’utilisateur et que les variables indicées soient prédéfinies et en nombre limité.
L’utilisateur n’a donc pas la possibilité de créer et d’utiliser une variable indicée autre que celles qui sont prédéfinies. La présence de variables indicées prédéfinies permet de prendre en compte plus simplement les sous-modèles.
3.2. Les variables du langage LAESH associées à la représentation
graphique
Les variables utilisées dans le langage LAESH sont de deux types :
Le type 1 pour une variable indicée dont le nom est prédéfini.
Le type 2 pour une variable simple dont le nom est défini par l’utilisateur. Une variable de type 2 est obligatoirement définie dans le bloc 3.
Le Tableau 4-3 donne la liste des variables de type 1, leur signification et les blocs où elles peuvent apparaître. Les variables retenues sont des variables dont la valeur peut dépendre d’un certain nombre de paramètres telles que la charge.
Nom Signification Blocs
DE (I, J, K) Délai pour le passage de la phase I à la phase J dans la catégorie K 2,3
NB (I, J, K) Nombre d’exécutions de la boucle I de la phase J dans la catégorie K 3,4,..., N+3 NE (I, J) Nombre d’exécutions de la phase I dans la catégorie J 3,4,..., N+3
PC (I) Proportion de patients de catégorie I 2,3
PR (I, J, K) Probabilité de transition de la phase I à la phase J dans la catégorie K 2,3 PS (I, J) Proportion d’utilisation du chemin I de la catégorie J 2,3