Bernard ALEKSY1, Agnès BARRIER1, Michelle CHABROL2, Michel GOURGAND2, Sophie RODIER2

1. CHU de Clermont-Ferrand 2. LIMOS CNRS UMR 6158

1GISEH 20102-4 septembre 2010, Clermont-Ferrand

Modélisation des systèmes Modélisation des systèmes hospitaliers : du générique au hospitaliers : du générique au

spécifique. Application à une unité spécifique. Application à une unité de soins de médecine digestivede soins de médecine digestive

Contexte et problématiques◦ Contexte◦ Problématiques◦ Objectifs◦ État de l'Art◦ Démarche proposée

Présentation de notre démarche et de sa mise en œuvre◦ Utilisation de la méthodologie ASCI appliquée au sous-domaine

des unités de soins◦ Conception d’un outil d’aide à la décision pour le sous-domaine

basé sur un modèle de simulation à événements discrets

Instanciation de notre démarche et mise en œuvre de notre outil sur un système dédié

2

3

Contexte et Contexte et ProblématiquesProblématiques

Les unités de soins

◦ Peuvent être nombreuses dans une même structure hospitalière

◦ Sont généralement découpées en secteurs qui peuvent varier selon : les fonctions des ressources humaines voire les

ressources humaines elles-mêmes les plannings horaires

4

Nécessité pour les managers hospitaliers de connaître et comprendre leurs systèmes pour décider

« Managers hospitaliers » = interlocuteurs multiples (directeur d'établissement, médecin chef de service, cadre supérieur de santé…)

Systèmes hospitaliers reconnus comme des systèmes complexes

Besoin de méthodes et d'outils pour appréhender cette complexité

5

L’objectif principal de ces outils est de pouvoir agir :

◦ en amont sur le dimensionnement de la structure en termes d’effectif, sur la mise en place et la comparaison de règles d’organisation en termes de planning et d’affectation des ressources, de gestions des flux (humains, matériel, d’information) ;

◦ pendant le fonctionnement du système pour faire évoluer et adapter les règles d’organisation et d’affectation des ressources et réagir aux événements aléatoires ;

◦ en aval pour évaluer la performance du système.

6

Différentes méthodes issues de la recherche opérationnelle pour apporter des solutions aux principales problématiques liées aux unités de soins :◦ l’analyse statistique, principalement utilisée pour la planification des lits (Gorunescu

et al., 2002; Nguyen et al., 2005)◦ la simulation (Ridge et al., 1998; Ashbi et al., 2008; Chauvet et al., 2008; Wang et al.,

2009) ◦ la théorie des réseaux de files d'attente (Gorunescu et al., 2002)◦ la modélisation mathématique (Akcali et al., 2006; Burke et al., 2008)◦ une combinaison entre plusieurs de ces méthodes (Bretthauer et Côté, 1998; Kim et

al., 1999; McManus et al., 2004; Tutuncu et Nexlands, 2009)

Le niveau de finesse de la modélisation varie selon les entités considérées (ressources, activité, patient) mais ne dépasse qu’exceptionnellement le niveau mesoscopique, se contentant la plupart du temps du niveau le plus agrégé (macroscopique) pour la décomposition de l’activité 

Les ressources humaines sont rarement prises en compte

Les approches et les outils sont généralement dédiés à un système

7

Méthodologie de modélisation ASCI

(Analyse, Spécification, Conception, Implémentation)

8

Utilisation de la méthodologie de modélisation appliquée aux Systèmes Hospitaliers (ASCI-SH):◦ Conception d'un modèle de connaissance générique pour le

sous-domaine des unités de soins◦ Création d'une bibliothèque de composants logiciels pour le

sous domaine◦ Proposition d'un modèle de résultats pour le sous domaine

Conception d'un outil d'aide à la décision pour le sous-domaine basé sur un modèle de simulation à événements discrets

Instanciation de notre démarche et mise en œuvre de notre outil sur un système

9

10

11

Utilisation de la Utilisation de la méthodologie de méthodologie de

modélisation ASCI modélisation ASCI appliquée au sous-domaine appliquée au sous-domaine

des unités de soinsdes unités de soins

Découpage du sous-domaine en trois sous-systèmes :◦ Sous-système physique (SSP)◦ Sous-système logique (SSL)◦ Sous-système décisionnel (SSD) Aspect statique : diagramme de classes UML

Modélisation des principales entités au niveau microscopique :◦ les ressources matérielles◦ les ressources humaines◦ le patient◦ l'activité

12

Introduction de concepts permettant de faire varier le niveau de finesse de la modélisation :

◦ Les classes « Ressource » « Type de ressource matérielle » et « Fonction de ressource humaine »  pour les ressourcesLa classe « Zone » pour la localisation des ressources humaines et matérielles

◦ La classe « Parcours » permet de faire varier le niveau de modélisation choisi pour le patient

◦ Les classes « Activité » et « Traitement élémentaire » et les attributs utilisés font varier le niveau de modélisation de l’activité

13

14

+Sous-type+Capacité

Ressource Matérielle+Spécialité+Expertise

Ressource Humaine

+Identifiant patient+Pathologie patient+Entrée patient+Sortie patient+Lourdeur

Patient

+Identifiant type+Nom type+Quantité type

Type Ressource Matérielle

+Identifiant fonction+Nom fonction+Quantité fonction

Fonction Ressource Humaine

+Calculer état() : Integer

+Identifiant planning+Nom planning+Horaires+Poste+Dépassement

Planning+Identifiant ressource+Nom ressource+Type ressource+Quantité minimum

Ressource

+Identifiant parcours+Nom parcours+Proportion

Parcours Patient

1..*

1

est localisé >

suit >

utilise >

*1

0..1

1..*

1

1..*

+Identifiant activité+Nom activité+Tour patient+Début activité+Fin activité

Activité

0..1

1..*

1

*

+Identifiant équipe+Nom équipe

Equipe

**

+Identifiant zone+Nom zone

Zone

+Identifiant secteur+Nom secteur

Secteur

1..*

1..*

est affectée >

est localisée >

1 *

intervient >

1

***1..*

1..*

1..*

mobilise >

*

*

1..* 1

1

11..*

Lieu

est rattachée >

0..1

est rattachée >

est ratachée >

*

1..*

1..*

*

*

*

+Identifiant chemin+Nom chemin

Chemin

*

correspond >

*

*

1

*1..*

1

0..1

0..1

+Mesurer() : Decimal

+Identifiant capteur+Nom capteur+Type capteur+Elément capteur+Type de mesure

Capteur

1*

0..1

*0..1

1..**

bénéficie de >

+Estimer la duree()+Calculer les statistiques()

+Identifiant traitement+Nom traitement+Type traitement+Spécialité+N° tour patient+Début traitement+Fin traitement+Retard autorisé+Type de durée+Paramètres durée+Niveau de priorité+Niveau de préemption+Autorisation avt prempt+Temps supplémentaire+Facultatif+Précédence+Partage de ressource+Toutes ressources+Facteur temps+Temps avant mobilisation+Temps avant préempt+Probabilité de réalisation

Traitement élémentaire

ContrainteRègle

Contrainte Positivité

ContraintePrécédence

Priorisationdes traitements

Préemption des ressources

Intervention des ressources

* * *

*

Gestion des stocks

*

*** *

** **

ContrainteCapacité

*

SSD

SSL

SSP

Diagramme de classes d’analyse

Spécification du comportement des entités◦ Parcours patients◦ Fonction des acteurs◦ Activités aléatoires

Aspect dynamique : Chaînes de Processus Événementielles (CPE) et arbres de fonction ARIS complétés par :

15

les règles de composition des équipes (opérateurs « et », « ou », « ou exclusif »…)

les attributs de la classe « Traitement élémentaire » associés à chaque fonction

Spécification des règles de gestion

16

Ex : Règles de gestion liées à l’intervention des ressources humaines

Règle n°1

Les ressources interviennent prioritairement dans leur secteur d’affectation. Elles peuvent ensuite éventuellement intervenir dans des zones ne faisant pas partie de leur secteur d’affectation.

Règle n°2

Si des ressources humaines disponibles sont appelées dans un autre secteur que leur secteur d’affectation, l’opération i appelle les ressources par ordre de proximité de leur localisation. Si plusieurs équipes de ressources distinctes peuvent être appelées pour réaliser le traitement, c’est la dernière équipe de ressources (qui correspond souvent à la plus « allégée ») qui est appelée.

Règle n°3

Pour qu’un traitement élémentaire i puisse préempter les ressources occupées sur un autre traitement k, il faut :

que la priorité de i soit élevée ([Traitement élémentaire].Niveau de priorité) ;

que le traitement k autorise la préemption ([Traitement élémentaire].Niveau de préemption) ;

que l’écart de priorité entre les deux traitements pour lequel k accepte d’être préempté, soit atteint ([Traitement élémentaire].Niveau de préemption).

Règle n°4

Si des ressources humaines, occupées sur un traitement i, sont préemptées pour intervenir prioritairement sur un traitement k, le traitement k qui préempte les ressources appelle prioritairement les ressources utilisées dans des zones de soins non directes (c’est à dire sans patient : bureau, locaux techniques...) puis il appelle les ressources par ordre de proximité de leur zone d’occupation. Si plusieurs équipes de ressources distinctes peuvent être appelées pour réaliser le traitement, c’est la dernière équipe de ressources qui est appelée.

Dérivation du diagramme de classes d'analyse en diagramme de classes de conception

Conception de la bibliothèque de composants logiciels pour le sous-domaine des unités de soins

17

Méthodes localesClasse de conception

Méthodes (composants logiciels)

Trait_el Priorisation des traitements en attente et en cours Accompagnement des patients par les ressources

humaines Changement dynamique de la priorité d’une activité Estimation de la durée des traitements élémentaires

Resultats_Trait Calcul et mise en forme des résultats sur les traitements élémentaires et les patients

Resultats_RessH Calcul et mise en forme des résultats sur les ressources humaines

Resultats_RessM Calcul et mise en forme des résultats sur les ressources matérielles

Méthodes globales (composants logiciels concernent plusieurs classes) Constitution des combinaisons de ressources pour la réalisation des traitements

élémentaires Calendrier d’arrivée des patients Affectation des patients aux lieux et aux jours Réalisation des plannings horaires des ressources Affectation des ressources aux plannings et secteurs Recherche de la ressource humaine la plus proche du lieu d’exécution d’un

traitement élémentaire Préemption des ressources Recueil et mise en forme de la trace du système

18

+id_Act : Integer+nom_Act : String+tourOp_Act : Integer+deb_Act : Integer+fin_Act : Integer+trait_Act : Collection (Trait_el)+chemin_Act : Chemin_

Activite_ +Contrainte_Capacite()

+id_RessH : Integer+nom_RessH : String+type_RessH : Integer+qtemin_RessH : Integer+spec_RessH : Integer+expert_RessH : Integer+fct_RessH : Fonction_RH+serv_RessH : <non spécifié>_+lieu_RessH : Lieu_+sect_RessH : Secteur_+zone_RessH : Collection (Zone_)+planning_RessH : Table (Planning_)+eq_RessH : Collection (Equipe_)+capt_RessH : Collection (Capteur_)

Ress_h

+id_Pat : Integer+patho_Pat : String+input_Pat : Integer+output_Pat : Integer+lourdeur_Pat : Decimal+parc_Pat : Parc_Pat+Trait_Pat : Collection (Trait_el)

Patient_

+id_Parc : Integer+nom_Parc : String+proportion_Parc : Decimal+chem_Parc : Collection (Chemin_)+patient_Parc : Collection (Patient_)

Parc_Pat

+id_Chem : Integer+nom_chem : String+activite_Chem : Collection (Activite_)-parcours_Chem : Parc_Pat

Chemin_

+Priorisation_Traitement()+Intervention_Ressources()+Preemption_Ressource()+Contrainte_Precedence()+Estimer_Duree()

+id_Trait : Integer+nom_Trait : String+type_Trait : Integer+spec_Trait : Integer+parc_Trait : Integer+tour_Trait : Integer+debut_Trait : Integer+fin_Trait : Integer+retard_Trait : Integer+typeDuree_Trait : String+duree_Trait : Vecteur (Integer)+prio_Trait : Integer+preempt_Trait : Integer+autorisation_Trait : Integer+tpsSupp_Trait : Integer+facultatif_Trait : Boolean+precedence_Trait : Vecteur (Integer)+partageEqRessH_Trait : Integer+toutesRessH_Trait : Boolean+muliTps_Trait : Vecteur (Decimal)+tpsAvMobi_Trait : Integer+tpsAvPreempt_Trait : Integer+proba_Trait : Decimal+patient_Trait : Collection (Patient_)+nbEqRessH_Trait : Integer+combiEqRessH_Trait : Collection (Ress_h)+nbRessM_Trait : Integer+ressM_Trait : Collection (Ress_h)+lieu_Trait : Lieu_+activite_Trait : Activite_+evaluer_Trait : Collection (<non spécifié>)

Trait_el

+Contrainte_Capacite()+trait_Lieu : Colllection (Trait_el)

Lieu_

+id_Capt : Integer+nom_Capt : String+type_Capt : String+elt_Capt : Integer+indice_Capt : String+trait_Capt : Collection (Trait_el)+ress_Capt : Collection (Ress_h)

Capteur_

+Mesurer()+Calculer_Statistiques()

+id_ResultT : Integer+id_Capt : Integer+id_Trait : Integer+txt_ResultT : String+num_ResultT : Decimal

Resultat_Trait

+Mesurer()+Calculer_Statistiques()

+id_ResultRH : Integer+id_Capt : Integer+id_Trait : Integer+txt_ResultRH : String+num_ResultRH : Decimal

Resultat_RessH

+id_Sect : Integer+nom_Sect : String+zone_Sect : Collection (Zone_)+ressH_Sect : Collection (Ress_h)

Secteur_

+id_Zone : Integer+nom_Zone : String+sect_Zone : Collection (Secteur_)+ressH_Zone : Collection (Ress_h)+ressM_Zone : Collection (Ress_m)

Zone_

+id_Eq : Integer+nom_Eq : String+ressH_Eq : Collection (Ress_h)+trait_Eq : Collection (Trait_el)

Equipe_

+Contrainte_Positivite()

+id_FctRH : Integer+nom_FctRH : String+qte_FctRH : String+ressH_FctRH : Colllection (Ress_h)

Fonction_RH

+Contrainte_Positivite()

+id_TypeRM : Integer+nom_TypeRM : String+qte_TypeRM : Integer+ressM_TypeRM : Collection (Ress_m)

Type_RM

+Calculer_Etat()

+id_Plan : Integer+nom_Plan : String+horaires_Plan : Table (Integer)+poste_Plan : String-depass_Plan : Table (Integer)+ressH_Plan : Collection (Ress_h)+ressM_Plan : Collection (Ress_m)

Planning_

+Contrainte_Capacite()

+id_RessM : Integer+nom_RessM : String+type_RessM : Integer+qtemin_RessM : Integer+sstype_RessM : Integer+capacite_RessM : Integer+type_RessM : Type_RM+serv_RessM : <non spécifié>_+lieu_RessM : Lieu_+zone_RessM : Collection (Zone_)+planning_RessM : Table (Planning_)+capt_RessM : Collection (Capteur_)

Ress_m

+Mesurer()+Calculer_Statistiques()

+id_ResultRM : Integer+id_Capt : Integer+id_Trait : Integer+txt_ResultRM : String+num_ResultRM : Decimal

Resultat_RessM

Dia

gram

me

de C

lass

es d

e Con

cept

ion

19

20

Conception d’un outil d’aide à la Conception d’un outil d’aide à la décision pour le sous-domaine décision pour le sous-domaine

basé sur un modèle de basé sur un modèle de simulation à événements discretssimulation à événements discrets

21

Objet UML ARIS / Structure de données

WITNESS

Patient CPE AttributSecteur Attribut

d’opération élémentaire

Module

Ressources matérielles

Ressources Stock/Machine

Ressources humaines

Ressources Opérateur

Traitement élémentaire

Opération élémentaire

Article

22

Modèle d’action WitnessUnité de Soins

Types d’article 1

Types de machines différentes 1

Nombre total de machines 196

Cycle de production par machine (maximum) 1

Types de stock 1

Nombre total de stocks 196

Types d‘opérateurs 10

Variables 63

Fonctions 20

Lignes de code(commentaires compris)

3 360

Ressources humaines4. Planning des ressources5. Découpage en secteurs6. Affectation des ressources aux plannings et

secteurs

Activités1. Fonctions des acteurs2. Parcours patient3. Activités aléatoires

Charge du système

Déplacements

7. Affectation des patients aux lits et aux jours

1

2

3

4 8. Matrice de routage

23

◦ Résultats globaux : occupation des lieux (lits) et des différents types de

ressources humaines ; nombres d’activités réalisées, non réalisées, en retard ; le temps de retard des activités par rapport à leur heure

de début/ de fin prévue.

◦ Résultats détaillés : pour chaque lieu : les temps et taux d’occupation et le

nombre de prises en charge ; pour chaque type de ressource humaine et chaque

ressource humaine : les temps et taux d’occupation par lieu, par opération élémentaire ;

pour chaque patient : les temps de traitement et les temps d’attente globaux, par lieu ou par opération élémentaire.

24

25

Instanciation de notre démarche et mise en

œuvre de notre outil sur un sur un système dédié

Sélection des entités considérées dans le diagramme de classes d’analyse

Spécification des règles de gestion

Spécification du comportement des entités

26

Fonctions des acteurs, parcours patient, activités aléatoires

27

Plannings des ressources, découpage en secteurs, affectation des ressources aux plannings et secteurs

28

Affectation des patients aux lits et aux jours

29

Matrice de routage

30

31

Résultats obtenus à partir du paramétrage, avant le lancement de la simulation◦ Occupation de l'unité de soins◦ Répartition des patients par parcours◦ Répartition de la charge entre tours

patients et selon les secteurs

◦ Répartition de la charge par jour et par lieu

32

Résultats obtenus par la simulation◦ Résultats globaux sur les activités

33

◦ Résultats détaillés sur les activités

34

◦ Occupation des ressources humaines taux d’occupation global des ressources par type de ressource ; taux d’occupation global et détaillé des ressources par planning ; taux d’occupation global et détaillé des ressources par secteur…

◦ Trace de la simulation

35

Taux d'occupation des ressources

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

AS ASH IDE

4

3

2

Jour (Tous) Binf Sect (Tous) BsupSect (Tous)

Moyenne de Tx d'occupation

Type Ind

Plannings

<< Retour Menu

Méthodologie ASCI-SH a permis de concevoir un modèle de connaissance générique du sous-domaine des unités de soins instanciable sur tout système du sous-domaine

Conception d'un outil d'aide à la décision totalement paramétrable et couvrant l'ensemble des horizons temporels

Démarche générique permettant également de prendre en compte les spécificités du sous-domaine

36

Eléments pris en compte

Activités programmées (fonctions des acteurs, parcours patients)

Activité aléatoires

Combinaisons de ressources humaines

Règles de priorités

Préemption des ressources

Variabilité des secteurs

Déplacement des ressources

37

Merci de votre attention

38 MOSIM’10 10 au 12 mai 2010 - Hammamet - Tunisie