Thomas Franck

Paolo Bercelli

Saber Aloui

Vincent Augusto

A GENERIC FRAMEWORK TO ANALYZE AND IMPROVE PATIENT PATHWAYS WITHIN A HEALTHCARE NETWORK USING PROCESS MINING AND DISCRETE-EVENT SIMULATION

Congestion in the Emergency Department (ED) is one of the most important issues in healthcare systems. The lack of downstream beds can deteriorate the quality of care for patients who need hospitalization after an ED visit. We propose a generic simulation model in order to analyze patient pathways from the ED to hospital discharge. The model is adaptable for all pathologies and can include several hospitals within a healthcare network. A pathway analysis using Process Mining is done in order to identify relevant pathways. Then we propose several designs of experiments in order to test medical unit capacity variations taking into account real data and practitioners expertise. A practical case study on stroke patient pathways in the Southern Brittany Hospital is proposed to illustrate the approach. Results show that the best way to improve the number of optimal pathways is to increase the capacity of Rehabilitative Care units.

INTRODUCTION

Context

Congestion in the Emergency Department (ED) is one of the most important issues in healthcare systems. This situation leads to an increase in length of stay, a decrease in the quality of care and the burnout of nursing staff. Two major causes of this congestion are identified: (i) unjustified Emergency Department visits and (ii) a lack of downstream beds. An unjustified emergency visit concerns a patient who have no health problem or a non-emergency health problem. This situation creates a work overload for the medical staff. The lack of downstream beds increases the length of stay in the Emergency Department because patients have to wait for a bed in a relevant medical unit. Sometimes patients are admitted to a medical unit that is not adapted to their pathology in order to decrease the ED congestion. This situation is problematic because it reduces the quality of care.

The Southern Brittany Hospital (SBH) is a merger of two hospitals: the Lorient Hospital and the Quimperlé hospital (since 2018). This fusion will lead to a major reorganization of the SBH in order to improve patient pathways from the admission in the emergency department to the discharge. Improving patient pathways can be done in two ways: (i) determining the most relevant pathways for a type of patients (e.g. pathology, age) and (ii) analyzing resource capacity requirements to avoid bottlenecks and queues. Business process modeling and process mining are relevant tools able to model patient pathways in hospitals and simulation allows a dynamic study. Simulation is one of the most suitable tools to test the impact on chosen indicators of any combination of changes [START_REF] Jun | Application of Discrete-Event Simulation in Health Care Clinics: A Survey[END_REF][START_REF] Zhang | Application of Discrete Event Simulation in Health Care: a Systematic Review[END_REF]. Franck, Augusto, Bercelli, and Aloui Many simulation studies focus on one type of pathology or a specific medical unit such as a geriatric care unit [START_REF] Franck | Performance Evaluation of an Integrated Care for Geriatric Departments Using Discrete-Event simulation[END_REF][START_REF] El-Darzi | A Simulation Modelling Approach to Evaluating Length of Stay, Occupancy, Emptiness and Bed Blocking in a Hospital Geriatric Department[END_REF], a stroke care unit [START_REF] Augusto | Redesigning the Neurovascular Unit of a Health Care Complex[END_REF][START_REF] Chemweno | Discrete Event Simulation Case Study: Diagnostic Path for Stroke Patients in a Stroke Unit[END_REF], a cardiology care unit [START_REF] De Bruin | Modeling the Emergency Cardiac In-Patient Flow: An Application of Queuing Theory[END_REF]. The SBH needs a model able to adapt to each pathology so the model must be generic.

We propose a case study on stroke because this pathology has several interesting characteristics: it is the first cause of acquired handicap, the third cause of death, and with more than 1 case each 4 minutes, stroke is a major public health challenge in France. A recent study [START_REF] Gabet | Déterminants de la Létalité à la Suite d'une Hospitalisation pour un Accident Vasculaire Cérébral en France, 2010-2015[END_REF] shows that stroke specialized medical units (in Neurology departments) reduce the lethality of patients by 2 after 1 month and after 1 year. In the SBH only 44% of stroke patients have access to such specialized units. For these reasons, improve stroke patient pathways is strategic for the SBH.

Scientific Contribution

In this paper we propose a generic simulation model in order to analyze all possible patient pathways from the Emergency Department to hospital discharge. The model can easily take into account several hospitals in order to be adaptable to the Southern Brittany Hospital situation (with two hospitals : Lorient and Quimperlé) and can be extended to a regional area. We focus our study on stroke patients but the model can analyze all pathologies. The resulting tool is a decision aid for hospital managers and health regional decision makers.

The remainder of this paper is organized as follows. The framework of the model is described in Section 2. In Section 3, we propose the case study of stroke patients. We perform a pathway analysis using process mining (Section 3.1) and two designs of experiments are introduced (Section 3.2). Results are detailed in Section 3.2 and discussed in Section 4. Conclusions and perspectives are given in Section 5.

DESCRIPTION OF THE MODEL

In this section, we present the overall framework of the model. We first define the different elements used in our model, then we present the admission policies for each category of patients. Finally, we propose a global overview of the methodology.

Global Framework

Definitions

Definition 1 (Patient) We consider a set I of patients indexed by i ∈ {1 . . . i . . . |I|}. We consider only hospitalized patients (when a patient requires a bed in a medical unit). A patient have different characteristics such as his/her age, a pathology and a geographic location.

We consider 2 categories of patients, divided into 2 different subsets I X ⊂ I and I Y ⊂ I (I X + I Y = I) :

• Unscheduled patients, i ∈ I X : these patients arrive at the hospital from the ED. Hospitalization was not planned before. These patients contribute to ED congestion. • Scheduled patients, i ∈ I Y : these patients do not arrive at the hospital from the Emergency department. Their hospitalization is planned before their admission. They are not directly connected to the ED congestion problem but they must be included in the model to achieve actual hospital occupancy.

Definition 2 (Medical unit) We consider a set of Medical Units M indexed m ∈ {1 . . . m . . . |M|}. There are different types of medical units with different characteristics such as the speciality (geriatric, neurology) or the geographic location (e.g. Lorient or Quimperlé in our case study). For each medical unit we consider a capacity C m and a waiting queue Q m .

Franck, Augusto, Bercelli, and Aloui Definition 3 (Patient Pathway) A patient pathway is a sequence of Medical Units where the patient has been hospitalized. We consider W i the pathway of the patient i where

W i =< M i1 . . . M is . . . M i|S i | >. M is
is the Medical Unit of the patient i at the step s. A step is a stay in a medical unit (without duration consideration). We consider S i a set of steps of the patient i indexed s ∈ {1 . . . s . . . |S i |}. Definition 4 (Phase Sequence) A phase models the activity performed by/on a patient during his/her clinical pathway. We note H is the phase of patient i at step s. We consider a phase sequence H i =< H i1 . . . H is . . . H i|S| > that complete the patient pathway sequence W i . We consider 3 different phases:

• Waiting Phase (H is = 1): the patient in a MU waits for a bed in a more relevant MU. The length of stay in this phase must be short (less than 1 day if possible). • Acute Phase (H is = 2) : the patient in a MU receives appropriate care. This phase is the core of the hospitalization. This phase can be composed of several steps. For example a patient can be admitted in an Intensive Care Unit in Neurology and then go in a General Neurology Unit. • Rehabilitative Phase (H is = 3) : the patient recovers in a Rehabilitative Care Unit before discharge.

In the best pathway a patient should not go through any waiting phase. Rehabilitative phases are not mandatory.

Definitions for Specific Pathologies

In this section we extend the framework in order to analyze patient pathways for one or several specific pathologies. Definition 5 (Types of patients) A type of patients is a group of Unscheduled patients who have the same characteristics. At least they must be treated for the same pathology z where Z is a set of specific pathologies indexed z ∈ {1 . . . z . . . |Z|} (i ∈ I Pz ⊂ I X ). In addition a type of patients can include other parameters such as the age. For example elderly people can often require geriatric care. A relevant pathway for an elderly patient can be different than a young patient. Let G be the set of type of patients indexed by g ∈ {1 . . . g . . . |G|} and T i the type of patients g of the patient i. Definition 6 (Relevant Pathways) A relevant pathway is a pathway adapted to a type of patients g. Let L g be a set of relevant pathways indexed by l ∈ {1 . . . l . . . |L g |} and RW lg the Relevant Pathway l of the type of patients g.

Relevant pathways only consider the acute phase of pathways. We do not take the waiting phase into account because this phase does not depend on medical care but on the occupancy of the hospital.In addition the rehabilitative phase is also not considered in relevant pathways because this phase depends on the requirement of the patient i. We consider a binary parameter R i , R i = 1 when the patient i requires a Rehabilitative Phase, 0 otherwise. Relevant pathways RW lg are also ranked by relevancy from l = 1 (the most relevant pathway) to l = |L g | (the worst relevant pathway).

In order to adapt our model to each situation we introduce the concept of substitution options. It happens that 2 different medical units can perform care for patients without major differences. In this case we consider a substitution option. Definition 7 (Substitution Options) We consider SO lgs , the substitution option of the pathway l for the type of patients g at the step s. If there is a substitution option, SO lgs = m where m is the substitution medical unit, SO lgs = / 0 if otherwise. Example 1 RW 1,2 =< 2, 5, 7 > and SO 1,2,2 = 6 means that pathways < 2, 5, 7 > and < 2, 6, 7 > for patients belonging to type number 2.

Franck, Augusto, Bercelli, and Aloui

Admission Policies

In this section we will present admission policies for Scheduled patients and unscheduled patients who are not concerned by a specific pathology (section 2.2.1) and patients concerned by a specific pathology z (section 2.2.2). Example 2 We consider the pathway of an unscheduled patient composed of 3 steps (|S i | = 3). We consider medical units 4, 5 and 6 (respectively medical units of steps 1, 2 and 3). The pathway of the patient i is W i =< 4, 5, 6 > and the phase sequence is H i =< 1, 2, 3 >. The patient has first a waiting phase (H i1 = 1) in MU 4 (Very Short Stay Unit). Then the patient goes to MU 5 for the Acute Phase (H i2 = 2). At the decision point D1 we check if there is an available bed in the medical unit 5. If it is the case the patient is admitted in the medical unit 5. If it is not the case the patient remains in the previous medical unit (M is-1 = 4 in our case) and is added to the queue of his/her future medical unit : Q 5 . At step 3 the patient has a Rehabilitative phase (H i3 = 3), decision D2 is exactly the same way as decision D1.

General Admission Policy

Example 3 We consider the pathway of an unscheduled patient. In this case the database does not indicate that the patient performed a waiting phase. If we consider the same medical units than the previous example, the pathway of the patient i is W i =< 5, 6 > and the sequence of phases is H i =< 2, 3 >. The patient started his/her pathway by the acute phase (H i1 = 2) but in the simulation there is not necessarily an available bed

Franck, Augusto, Bercelli, and Aloui in medical unit 5. In this case the patient is placed in queue Q 5 and in the Medical Unit that represents the ED (for example m = 0). Example 4 We consider the pathway of a scheduled patient. For these patients the pathway is always W i =< M i1 > and the phase sequence H i =< 2 >. If the bed is not available the patient is placed in the queue of the medical unit and wait at home (because he/she did not go to ED).

Specific Pathologies Admission Policy

For patient who have a specific pathology, the admission policy must include the different relevant pathways and the possibility of substitution options. Figure 2 presents the admission policy when the patient i ∈ I Pz .

Example 5 First the patient arrives at an Emergency Department and requires a hospitalisation. At step 1 the patient must be assigned to a relevant pathway l for his/her type. First we check for RW 1T i if there is an available bed in the structure M 1g1 . If this condition is verified (decision D1) the patient is assigned to the Relevant Pathway RW 1g and is admitted to the medical unit M 1g1 . If D1 is false, the same operation is done for each Relevant pathway l (decision D2) until the pathway |L g | (decision D3). If there is no possible option the patient waits in the ED (m = 0) until he/she can be assigned to a pathway. Then for each step s of the pathway RW lg we check if the medical unit M lgs has an available bed. If the condition is verified the patient i is admitted to the unit (decision D4). Otherwise we check if there is a Substitution Option (SO lgs = / 0) and if there is an available bed in this medical unit. If the condition is true the patient is admitted to this alternative solution (decision D5), otherwise the patient remains in the medical unit M lgs-1 and waits in queue Q M lgs . After the last step |S| of pathway RW lg we check if the patient requires a rehabilitative phase (decision D6). If it is not the case the patient has finished his/her pathway and can return home. If the condition is true the patient goes to a Rehabilitative Care medical unit as soon as a bed is available (decision D7). Otherwise the patient remains in the medical unit M lg|S| .

Medical Unit of step 1 pathway 1 (𝑴 𝟏𝒈𝟏 )

Step 1

Step Step |S|

Rehabilitative

Care Medical Unit

End of the pathway

Waiting in Medical

Methodology

In this paper we propose a formal framework along with a methodology presented in Figure 3. It can be divided into 3 steps: (1) Data preparation, (2) Patient pathways setup and (3) Simulation model implementation.

In Step (1) data is extracted and prepared using national medico-administrative databases in order to use the framework in any hospital. For example, in our case study, we extract all hospitalizations of the Lorient and Quimperlé hospitals. From this extraction, we build two databases: (i) the scheduled patients database and (ii) the unscheduled patient database.

Franck, Augusto, Bercelli, and Aloui

In Step (2), for scheduled patients (i ∈ I Y ) and unscheduled patients who have not a specific pathology (i ∈ I X -I Pz ) all settings are extracted from the database: arrival date, pathway sequence, and the length of stay in each medical unit. For a specific pathology we use Process Mining to analyze pathways from the database and extract relevant and substitution pathways. Process Mining is a method to determine processes using data mining algorithms and filters.

In Step (3) the Discrete-Event Simulation model is implemented and allows the simulation taking into account the settings of patients and their admission policy. Each patient arrives in the system at a specified arrival date and is discharged when he/she has performed all steps of his/her pathway. The design of experiments proposes variations of medical unit capacities (e.g. number of beds) using design of experiments.

CASE STUDY: STROKE PATIENT CARE PATHWAY

In this section we apply the methodology defined in Section 2.3 to analyze pathways of stroke patients (specific pathology) using Process Mining. Results have been reviewed by practitioners of the Southern Brittany Hospital.

Stroke Pathway Analysis

Data

We use a data-set extracted from the French National Data-Set of Hospitalizations. We included all ischemic strokes for the year 2018 in the South Brittany Hospital (Quimperlé Hospital and Lorient Hospital). This set includes a total of 534 cases with 170 variants of pathways.

Franck, Augusto, Bercelli, and Aloui

Set of Medical Units

In order to reduce the model complexity we select the most used medical units as listed in Table 1. There are 3 medical units in the neurology department located in the Lorient hospital: (1) the Neurovascular Intensive Care Unit (NICU) is a medical unit dedicated to stroke and the very acute phase of this pathology; (2) the Neurovascular Unit (NU) is also specialized in stroke care; (3) the General Neurology Unit (GNU) concerns all neurological diseases. There are 2 Polyvalent Medicine Units we also considered: one located in the Lorient hospital (PMUL) and one located in the Quimperlé hospital (PMUQ). Finally we also considered two Geriatric Units (GUL and GUQ). Geriatric Unit (GUQ) Quimperlé

Process Mining Analysis

We use the process mining software ProM to analyze the activity of stroke hospitalizations in the Southern Brittany Hospital. Such analysis is used to define optimal pathway for stroke patients and types of patients. The optimal pathway. We call "optimal pathway" the most adapted pathway for a stroke patient. This pathway is composed of the NICU and then the NU (RW =< 1, 2 >). The NU and the GNU are located in the same place at the Lorient hospital and the medical staff is common for both medical units. Thus the GNU can be considered as a substitution option (RW =< 1, 3 >). In 2018 those pathways account for 44% of stroke hospitalizations (235 cases). Among these 235 cases, 63 used the substitution option GNU (27% of the optimal pathway). A recent study [START_REF] Gabet | Déterminants de la Létalité à la Suite d'une Hospitalisation pour un Accident Vasculaire Cérébral en France, 2010-2015[END_REF]) confirms that these pathways should be used for all patients to improve the quality of care.

Elderly Patients We consider a patient as an elderly patient if he/she is aged of 80 years or more. The stroke data-set is composed of 52% elderly people (276). Among these patients, 32% (89) of followed optimal pathways. A suitable pathway for an elderly patient is to go to a geriatric medical unit. These patients have generally several chronic pathologies and geriatric units are able to handle these problems. This kind of pathways represents 28% of pathways (76 cases) of elderly pathways. Polyvalent Medicine Units can also take into account several pathologies but are less adaptable to elderly people issues. Such pathways represents 20% of elderly pathways (57 cases).

Geographic areas. There are two possible starts of pathways for stroke patients of the Lorient area: (i) the Qimperlé ED and (ii) the Lorient ED. The number of patients coming from the Quimperlé ED (resp. Lorient ED) is 94 (17%) (resp. 440 (83%)). The number of patients from Quimperlé who performed an optimal pathway is 12 (13%) and 223 for patients from Lorient (51%). There is a strong difference of quality of care for stroke patients depending to the initial ED location.

Relevant Pathways for Stroke Patients

According to the pathway analysis proposed in Section 3.1.3 we define types of patients g and related sets of relevant pathways l. We consider 4 types of patients characterized by their age and the location of the initial ED, summarized in Table 2.

= 3 < 80 1 RW 21 =< 4 > / 0 > 80 2 RW 12 =< 1, 2 > SO 122 = 3 > 80 2 RW 22 =< 6 > / 0 > 80 2 RW 32 =< 4 > / 0 Quimperlé < 80 3 RW 13 =< 1, 2 > SO 132 = 3 < 80 3 RW 23 =< 5 > / 0 > 80 4 RW 14 =< 1, 2 > SO 142 = 3 > 80 4 RW 24 =< 7 > / 0 > 80 4 RW 32 =< 5 > / 0
Patients of type 1 are young patients (< 80 y.o.) arriving from the Lorient ED. Relevant pathway (RW 11 ) is the optimal pathway: NICU then NU. A substitution option is possible at step 2 with GNU instead of NU. Second relevant pathway (RW 21 ) is to go to the PMUL. Nevertheless this pathway is not specialized in Neurovascular issues so the quality of care is lower than the pathway 1.

Patients of the type 2 are elderly patients arriving from the Lorient ED. The most relevant pathway (RW 12 ) is the optimal pathway because the Neurology Department remains the best option for stroke patients. The second relevant pathway (RW 22 ) is composed of 1 step, the geriatric unit (GUL). In section 3.1.3, we saw that geriatric units are a good option to handle the problem of poly-pathology of elderly people. The third pathway for this type of patients (RW 32 ) is the PUL.

We consider 2 other types of patients (3 and 4) when patients come from the Quinperlé ED. Patients of type 3 (resp. 4) are young patients (resp. elderly patients).

Simulation

In this article we will consider two designs of experiments (DoE) to improve the quality of care for stroke patients (i.e. increase the number of patients following an optimal pathway as presented in Section 3.1.3 composed of the NICU and then the NU). We increase the number of of NICU and NU beds. In the DoE 1 all distributions are based on the data set. In DoE 2 we use theoretical distributions according to practitioners expertise.

To evaluate performances of scenarios we use 4 Key Performance Indicators (KPIs). KPI1 is the number of optimal pathways (best for stroke patients). KPI2 is the Average Queue in NU. KPI3 is the length of stay in NICU. KPI4 is the average demand of Rehabilitative Care Unit (RCU) per day. We use this KPI only in DoE 2.

We use AnyLogic Personal Learning Edition 8.5.1 to implement the model. The data set is composed of all hospitalized patients in the Southern Brittany Hospital from January 2018 to July 2018. It represents 6 months of hospitalizations with 1 month of Warm Up. We run 20 replications. The arrival date of each patient is based on the data set.

Design of Experiments 1

In this DoE we computed length of stay distributions of Stroke Patients (i ∈ I P1 ) on the data set (Table 3). To validate these distributions we simulated the model using real pathways of patients (W i ) without limitation of capacities. We compared with a 95% confidence interval different parameters between data set and the simulation. This parameters are the mean occupation, the maximum occupation and the average length of stay for each medical unit concerned by distributions.

According Neurology practitioners the length of stay of the NICU is often impacted by the lack of available beds in NU. In theory the length of stay in these units is at least 2 days and practitioners estimated Franck, Augusto, Bercelli, and Aloui the average LOS at 2.5 days. We adjusted the distribution in order to respect the observed average length of stay with the current hospital capacity (3.7 days) and respect a theoretical length of stay for these units (around 2.5 days) when there is no capacity constraint. It allows us to measure the impact of scenarios on the NICU LOS. Table 4 shows scenarios of the design of experiments. We vary the number of NICU and NU beds from the current capacities to configuration with at most 10 additional beds (NU+NICU). We determined the number of NU beds according to the number of additional beds and the number of NICU beds. For example in the scenario with 4 additional beds and 8 NICU beds, the number of NU beds is 14. For better readability we only represent scenarios with 6, 7, 8 and 10 NICU beds. Figure 4 shows the number of optimal pathways (KPI1) and Figure 5 the average number of patients in the NU queue (KPI2). Figure 4 shows that the average number of the optimal pathway increases in all scenarios. The current number of beds (6 NICU and 12 NU) allows 120.85 optimal pathways on average. If we add NU beds, the KPI1 improves significantly until 5 added beds (151.3).Then the curve follows an asymptotic trajectory.

To improve these results it is necessary to increase the number of NICU beds. The number of optimal pathways for scenarios with 7 NICU beds is 184.8 with 10 added beds (21 NU beds). Scenarios with 8 and 10 NICU beds have no significant difference. The best average number of optimal pathways with 10 added beds is 212.5 (10 NICU beds and 16 NU beds). Figure 5 shows the average number of patients in the NU Queue. When we increase the number of NICU beds, the average number of patients in queue increases. There are more people in NICU but proportionally less available beds in NU and it creates a bottleneck. The amount of KPI2 strictly increases when there are 10 NICU beds (12,8 for for 4 additional beds). When we increase the number of NU beds the average number of patients in NU queue decreases in each situation. These results indicate that the number of NICU and NU beds must be balanced to avoid queues. When there are enough NU beds the average number of patients in queues tends to 0.

Figure 6 shows the LOS of patients in NICU. In the current situation the LOS is 3.56 days. When the number of NU beds increases, this duration of KPI3 decreases until 2.44. It is the lowest value possible because the length of stay in this medical unit is at least 2 days (average 2.5 days). When the number of NCIU beds increases the length of stay in NICU increases too (until 6.19 days for 10 NICU beds and 12

Franck, Augusto, Bercelli, and Aloui NU beds). In this situation there is an improvement of the quality of care (KPI1) but it creates a bottleneck. This bottleneck induces a raise in queues (KPI2) and a raise in the LOS (KPI3).

Design of Experiments 2

In DoE 1 we adjusted the NICU distribution in order to improve the behavior of the model. The NU is also impacted by a lack of available places in rehabilitative care units. Often patients begin the rehabilitative phase in the NU and they become bed blockers. Neurology practitioners estimated theoretical LOS for NICU and NU without waitings due to Rehabilitative Care Units occupation. We used triangular distributions presented in Table 5. We consider that each patient with a length of stay of more than 7 days in NU requires a Rehabilitative Care Unit (R i = 1). It represents 70% of stroke patients. We use a similar design of experiments than design of experiments 1 but we allow only 5 additional beds. Figure 7 shows that the number of optimal pathways increases strongly compared to the design of experiments 1. In the current situation (6 NICU beds and 12 NU beds) the average number of optimal pathways is 166.3. In design of experiments 1 this result corresponds to scenarios with 4 additional beds (for example 8 NICU beds and 14 NU beds). In addition adding NU beds does not improve KPI1.

Franck, Augusto, Bercelli, and Aloui Increasing the number of NICU beds improve strongly this KPI. The scenario with 4 additional beds and 10 NICU beds allows 245.15 optimal pathways on average. There is 259 stroke patients in the data-set so it represents 94% of optimal pathways. The Figure 8 shows the average demand on Rehabilitative care per day. Scenarios with 6 NICU beds require on average 0.65 Rehabilitative care place per day to allow the new distributions. When the number of NICU bed increases the average number of demands increases too. Scenarios with 10 NICU beds require on average 0.98 rehabilitative care beds per day.

DISCUSSION

Many simulation models are specific medical unit (or department) based. [START_REF] Günal | Discrete Event Simulation for Performance Modelling in Health Care: A Review of the Literature[END_REF] explain this trend by the fact that decision-makers often need quick and targeted responses. Attempts to model an entire hospital are rare and require simplifications [START_REF] Pidd | Tools for Thinking: Modelling in Management Science[END_REF]. Our model allows decision-makers to choose their simplifications and to define their study using a unique framework. We can also integrate several hospitals, (e.g., Lorient and Quimperlé) and test different DoE. Numerical results highlight differences between DoE 1 and 2. In DoE 1, increasing the number of optimal pathways (KPI1) requires to add a lot of beds. Adding NU beds increases slowly KPI1 but reduces the average number of patients in NU queue and improve the NICU LOS. Adding NICU beds has better results for KPI1 but it increases the NU queue and the LOS of NICU. In DoE 1, the NU is a bottleneck. It is possible to improve the quality of care but the the gain per added bed is limited.

In DoE 2 we have changed the length of stay distributions of the Neurology Department (NICU, NU and GNU). These new distributions are based on the expertise of practitioners. They consider that the lack of available beds in Rehabilitative Care Units forces them to begin the rehabilitative phase in NU or in GNU. We used theoretical length of stay to correct this problem. Results in this design of experiments are significantly better than results obtained in DoE 1. In DoE 2 the NICU becomes the bottleneck of the system and adding beds in this unit increases strongly the number of optimal pathways. Adding 4 NICU allows to reach 94% of optimal pathways. This configuration reduces the inequality between the Lorient ED and the Quimprelé ED.

Such good results must be qualified because we made strong assumptions. New distributions of LOS have been determined according to estimations of doctors and not based on a real data-set. In addition this configuration requires a large number of rehabilitative care solutions (in average 1 per day when we add 4 NICU beds). It requires important investments in Rehabilitative Care Medical Unit.

CONCLUSION AND FUTURE WORKS

In this paper we proposed a generic framework in order to model every patient pathways in a hospital or several hospitals. We introduced a formal modelling approach for care pathways within the hospital. We used Process Mining to determine with medical staff relevent pathways for a given pathology. Then we proposed two designs of experiments: (i) using LOS distributions based on real data and (ii) using LOS distributions based on the expertise of practitioners. Results show that it is possible to strongly improve the quality of pathways by increasing Rehabilitative Care Units capacity.

The genericity of the model opens many perspectives to extend this study: include other hospitals to test regional stroke management policies, use the model for other pathologies (with priority rules beetwen pathologies). For future works we plan to move the simulation model to a digital twin tool that can be used daily by practitioners.

Figure 1 :

 1 Figure 1: Examples of pathways for unscheduled and scheduled patients.

Figure 2 :

 2 Figure 2: Admission policy for specific pathologies.

Figure 3 :

 3 Figure 3: Global methodology.

Figure 5 :Figure 6 :

 56 Figure 4: KPI1 Avg. number of optimal pathways.

Figure 8 :

 8 Figure 7: KPI1 Avg. number of optimal pathways.

s Rehabilitative Phase Patient Arrival Medical Unit m of step s pathway 1 (𝑴 𝟏𝒈𝒔 ) Medical Unit of step 1 pathway l (𝑴 𝒍𝒈𝒔 ) Medical Unit of step 1 pathway

|𝑳 𝒈 | (𝑴 |𝑳 𝒈 |𝒈𝟏 )

Table 1 :

 1 Medical units for stroke patients in SBH.

	Medical Unit m Description	Location
	1	Neurovascular Intensive Care Unit (NICU) Lorient
	2	Neurovascular Unit (NU)	Lorient
	3	General Neurology Unit (GNU)	Lorient
	4	Polyvalent medicine Unit (PMUL)	Lorient
	5	Polyvalent medicine Unit (PMUQ)	Quimperlé
	6	Geriatric Unit (GUL)	Lorient
	7

Table 2 :

 2 Relevant pathways per type of patients for stroke patients.

	ED Unit	Age	Type of patients g Relevant Pathway RW lg Substitution Option SO lgs
	Lorient	< 80 1	RW 11 =< 1, 2 >	SO 112

Table 3 :

 3 Distributions per medical unit for stroke patients of DoE 1.

	Medical Unit m Description Distributions	Capacity
	1	NICU	lognormal(1.235, 0.506, 2) days	6 beds
	2	NU	lognormal(1.832, 1.032, 2) days	12 beds
	3	GNU	lognormal(2.083, 0.916, 1.5) days 10 beds
	4	GMUL	weibull(1.24, 13.5, 1.5) days	58 beds
	5	GMUQ	triangular(1,4, 16) days	42 beds
	6	GUL	gamma(5.38, 2.48, 1) days	22 beds
	7	GUQ	uniform(1, 20) days	38 beds

Table 4 :

 4 Scenarios for the DoE 1.

	Number of additional beds 0	1	2	3	4	5	6	7	8	9	10
	6 NICU beds	12 NU beds 13 14 15 16 17 18 19 20 21 22
	7 NICU beds	-	12 13 14 15 16 17 18 19 20 21
	8 NICU beds	-	-	12 13 14 15 16 17 18 19 20
	9 NICU beds	-	-	-	12 13 14 15 16 17 18 19
	10 NICU beds	-	-	-	-	12 13 14 15 16 17 18
	11 NICU beds	-	-	-	-	-	12 13 14 15 16 17
	12 NICU beds	-	-	-	-	-	-	12 13 14 15 16

Table 5 :

 5 Distributions per medical unit for stroke patients of DoE 2.

	Medical Unit m Description	Distributions
	1	Neurovascular Intensive Care Unit (NICU) triangular(2,2.5, 4) days
	2	Neurovascular Unit (NU)	triangular(1, 4, 7) days
	3	General Neurology Unit (GNU)	triangular(1, 4, 7) days

AUTHOR BIOGRAPHIES

THOMAS FRANCK is a post-doctoral researcher at the Center for Health Engineering at Mines de Saint-Etienne (EMSE) and at Groupe Hospitalier Bretagne Sud, France (GHBS). He received his Ph.D. in Industrial Engineering from Mines Saint-Etienne in 2018. His research interests include Discrete Event Simulation in health care systems. His email address is t.franck@ghbs.bzh.

VINCENT AUGUSTO is a Professor of industrial engineering and he is the head of the Center for Health Care Engineering at Mines Saint-Etienne. He received his Ph.D. in Industrial Engineering from Mines Saint-Etienne, France, in 2008 and the Habilitation à Diriger des Recherches degree from the University of Saint-Etienne, France, in 2016. He was a visiting scholar at CIRRELT (Centre Interuniversitaire de Recherche sur les Réseaux d'Entreprise, la Logistique et le Transport), University of Laval, Quebec, Canada in 2009 and 2015. His research interests include modeling, simulation, optimization of healthcare systems and their supply chains, process mining and machine learning applied to healthcare. His email address is augusto@emse.fr.

PAOLO BERCELLI is the medical information doctor of the Groupe Hospitalier Bretagne Sud, France (GHBS). His email address is p.bercelli@ch-bretagne-sud.fr.

SABER ALOUI has a Ph.D. in Risk Management (2007) from the Ecole des Mines de Paris, Doctoral team called "Centre for research on Risks and Crises". His research aims to develop and to formalize concepts and tools allowing to analyse the risk occurrence in large health care organizations. He is currently CIO of the Groupe Hospitalier Bretagne Sud, France (GHBS). His email address is s.aloui@ghbs.bzh.


Mathieu Escouteloup

Ronan Lashermes

Jean-Louis Lanet

Jean-Alain Fournier

Jacques Fournier

Recommendations for a radically secure ISA

Keywords: Instruction set architecture, hardware security context, side-channels

come

INTRODUCTION

In 2018, the Spectre [START_REF] Kocher | Spectre Attacks: Exploiting Speculative Execution[END_REF] and Meltdown [START_REF] Lipp | Meltdown: Reading Kernel Memory from User Space[END_REF] attacks received a wide attention by showing how unsecured our modern central processing units (CPUs) are. But it has been known for a long time that the hardware was a source of vulnerabilities (e.g. as shown in 2005 by Bernstein [START_REF] Daniel | Cache-timing attacks on AES[END_REF] and Percival [START_REF] Percival | Cache missing for fun and profit[END_REF]).

What makes these new attacks so important is that, in the meantime, software security as gained a lot of maturity. Hardware is becoming the weakest security link in our systems.

Motivation. To improve the security of our CPUs we must rethink how to design them by taking into account the security issues from the beginning. Numerous solutions have been proposed.

(1) Adding more privilege levels (trusted execution environments (TEEs) such as Keystone [START_REF] Lee | Keystone: An Open Framework for Architecting Trusted Execution Environments[END_REF], Hex-Five's MultiZone). (2) Ensuring stronger access control policies to access memory (physical memory protection (PMP), Morello/CHERI [START_REF] Woodruff | The CHERI capability model: Revisiting RISC in an age of risk[END_REF]). (3) Hardware hardening: build the processor around stronger primitives (CEA's IntrinSec project). (4) Circumventing the problem by modifying the software: for example the retpoline countermeasure is an instruction pattern intended to prevent hardware speculation (and failing in some edge cases).

All these solutions are needed, but there is one that we think is not explored enough: modifying the instruction set architecture (ISA) to enable the software/hardware interface to "talk" about security, even in the abscence of any memory management unit CARRV2020, May 2020, Virtual Workshop (MMU). The most notable works in this area are, as far as we know, from Yu et al. [START_REF] Yu | Data Oblivious ISA Extensions for Side Channel-Resistant and High Performance Computing[END_REF] and Ge et al. [START_REF] Ge | No Security Without Time Protection: We Need a New Hardware-Software Contract[END_REF] that propose to modify the ISA to fight timing side-channels.

Contribution. In this paper, we propose recommendations to design an ISA for CPUs supporting critical systems. These recommendations are centred around 3 themes. After giving our design guidelines in section 2, we show how to limit the ISA's power to mitigate some side-channels in section 3. We propose to restrict the ISA even more to have stronger control flow guarantees in section 4. Finally, we decribe a RISC-V extension to allow the ISA to express security boundaries in section 5. We conclude in section 6 by showing the links between our recommendations.

DESIGN GUIDELINES

We acknowledge that a trade-off is required between performance, energy consumption and security. To achieve a high CPU security, worthy of a critical system, we must compromise on both performance and energy consumption.

Principles

In order to guide our proposals, we identified a list of generic principles that help us decide if a feature should or should not be included in our secure system. We are following here the example given by Patterson and Waterman [START_REF] Patterson | The RISC-V Reader: An Open Architecture Atlas[END_REF] who give the following principles as RISC-V design guidelines: cost, simplicity, performance, isolation of architecture from implementation, room for growth, code size and programmability. Our own principles are listed below. Simplicity. To ensure security, we have to limit the attack surface. Simple systems can be modelled in an easier way, allowing the blue team to predict the behaviour of the system and therefore identify weaknesses. The simplicity principle opposes the guarantee of retrocompatibility: old interfaces must be tossed.

Principle of least privilege. Any entity in the system must only be able to do what it is designed to do and nothing more.

Habeas Corpus. The principle of least privilege requires compartmentalization, the habeas corpus principle is about the interaction between these compartments. A compartment management (creation, pause, data modification, . . . ) can only be performed from inside a compartment of higher power.

Transparency. The security of a system must not rely on its opacity (Kerckhoffs's principle). The secure system designer and user are usually not the same entities, and the first must prove the system security to the second.

Prove yourself. Human developers are error-prone. No amount of dedication can prevent the one mistake that will break a system security. Therefore, secure systems must push for and ease the use of proof-oriented software. A lot of properties can and must be proven: memory safety, absence of data races, no data leakage etc. Proofs must be everywhere, in hardware, in software and in the tools used for development.

Defence in depth. If a given property holds on a program, then we surely do not need additional hardware isolation. Mathematical proofs are only valid under a set of hypotheses. When the program runs on hardware and thus get a physical incarnation (power consumption, memory access timings etc.), then the hypotheses may change and as a consequence, proofs do not hold any more. As a result, several protection mechanisms, sometimes redundant, must be put in place to counteract the collapse of the abstractions.

Designing a new secure ISA

In the rest of this paper, we make recommendations to build a new secure ISA by relying on the RISC-V specification. As a consequence, the recommendations should be read as a modification of the RV32I base ISA to form a new one: RV32S (S as in Secure).

THE SEMANTICS OF SCA HARDENED INSTRUCTIONS

Since the cache timing attack on AES [START_REF] Daniel | Cache-timing attacks on AES[END_REF], software and hardware designers try to devise techniques to avoid such vulnerabilities.

The principle is to avoid any timing dependency on a secret value. Sometimes, it can be achieved in software by reordering the instructions.

But there are several difficulties with this technique: the application developer does not have perfect control on how the compiler generates instructions corresponding to its code. In particular, widespread compilers do not conserve timing semantics: today, timing sensitive applications must be written in assembly. Yet new research has shown that timing semantics preserving compilers are possible [START_REF] Barthe | Formal Verification of a Constant-Time Preserving C Compiler[END_REF].

Unfortunately, it is not enough if there is no guaranteed timing semantics at the ISA level. A classic example is an hardware multiplication whose duration depends on the data fed. In this case, the timing leakage reappears.

The conclusion is that we cannot let the sole responsibility of preventing side-channels falling on the developers' shoulders. Some confidentiality properties must be guaranteed by the hardware and the software ecosystem (compilers, libc, operating systems (OSs), . . . ) must take advantage of it. This idea has been explored by Yu et al. [START_REF] Yu | Data Oblivious ISA Extensions for Side Channel-Resistant and High Performance Computing[END_REF], with a RISC-V extension to ensure that confidential data is only handled by safe instructions, by tracking and propagating confidentiality labels on data.

Here we suggest simpler solutions: we rely on the compiler to know what is confidential or not, and we enable it to map confidential data to confidential registers, no hardware tracking needed.

Confidential registers

In order to communicate the desire to enforce stronger confidentiality with respect to side-channels, we can tag some registers as confidential. The micro-architecture must try to enforce this guarantee (with an effort related to its security profile) and the semantics of the instructions is modified in consequence.

Recommendation 1 Confidential registers Tag some registers (e.g. x8 to x15 ) as confidential, with the following semantic consequences.

• It is not possible to branch depending on a confidential register. • Instructions are authorized only if their timing is not data dependant (integer multiplication and division in particular may be forbidden depending on their hardware implementation). • They cannot be used as the source address in load and store instructions. Any violation of these rules should raise an hardware security fault.

In addition, the hardware must try to prevent any leakage on these registers' values. Depending on the security profile, these registers can be hardened: the values are masked to avoid power consumption leakage, the micro-architecture uses hardened execution units (e.g. masked computation) for instructions involving at least a confidential register, . . .

Recommendation 2 Automatic memory encryption

An additional behaviour can be attached to the use of confidential registers as destination registers for a load or as the second source register for a store. In this case, we can encrypt the confidential data in memory, as soon as it leaves the pipeline. Devising a sound encryption scheme for that purpose would require a paper of its own. If the hardware security contexts (HSCs) were used (concept developped in section 5), we could use the automatic encryption feature to bind a data to an HSC: the encryption key would depend on the current context, therefore preventing another context to read the data.

Consequence of confidential registers

Instructions at the confidentiality boundary, that have a confidential input and a public output or vice-versa, can be trivially detected. There is no need to forbid such instructions, but they should be carefully audited to ensure that the developer intention is respected.

On the software side, confidential registers allow the compiler to have a clear semantics for confidentiality: if a data is confidential, it must only be put into confidential registers. Doing an unsafe operation such as branching on a confidential register is now a compile time error (it cannot even be compiled).

Static analysis can now trivially stress out all the confidentiality boundaries (converting a confidential data into public data, . . . ), making it easier to detect flaws in the confidentiality policy. It becomes easier to prove such policies automatically, with e.g. a theorem prover.

Random number generator

A lot of security-related applications require a strong and reliable random number generator. Without an hardware random number generator, applications must harvest system-level entropy themselves (usually by timing peripherals). But system-level entropy cannot provide strong guarantee of randomness, and then a piece of software becomes responsible for converting this entropy into a suitable random number generator. All these steps may leak information through side-channels.

Recommendation 3 RNG instructions

An instruction for random number generation should be added. CSPRNG rd : a cryptographically secure pseudo-random number generator, following NIST SP 800-90A, to use for most purposes (including generation of cryptographic keys).

Adding the CSPRNG instructions changes the nature of the ISA. Without them, we can call the ISA functional: the conformance of a device to the specification can be tested by testing its functionalities. But a CSPRNG cannot be tested to know if it works properly: vulnerable random number generators can successfully pass all the randomness statistical tests. A good CSPRNG implementation can only be recognized by its design and implementation, not (only) by its functionality. The transparency of the becomes critical to build trust between designers and users. Now, the ISA has become a formal contract between software and hardware that is not only tied to functionality, that cannot be tested: it has become a formal ISA.

IMPROVING SECURITY GUARANTEES WITH STRICTER CONTROL FLOWS

Abusing the control flow is a common way to tamper with a system. Ensuring the static integrity of an application usually requires to compare the hash of the binary you are about to launch with a truth value stored somewhere safe. But the attacker can still abuse the legit instructions in your application, and reorder them to build their payload. This principle is behind return-oriented programming (ROP) [START_REF] Roemer | Return-Oriented Programming: Systems, Languages, and Applications[END_REF] that uses a chain of gadgets (instructions patterns of interest to the attacker) that are glued together with RETURN instructions.

Preventing ROP (and its variants) is a widely studied problem. Control flow integrity (CFI) tries to ensure that the control flow of the initial application is respected and not abused. CFI solutions usually verify that (forward) jumps and returns (backward jumps) can only go to legitimate addresses. These techniques can be implemented in software [START_REF] Abadi | Control-flow integrity principles, implementations, and applications[END_REF], now with the compiler automatically adding the verification code [START_REF] Tice | Enforcing Forward-Edge Control-Flow Integrity in GCC & LLVM[END_REF].

But CFI can also be proposed in hardware. In [START_REF] Davi | HAFIX: hardwareassisted flow integrity extension[END_REF], Davi et al. propose an efficient way to restrict where a jump can land to by adding new CFI dedicated instructions. The CHERI project proposes, among other things, to protect pointers with unforgeable capabilities [START_REF] Woodruff | The CHERI capability model: Revisiting RISC in an age of risk[END_REF]. SOFIA [START_REF] De Clercq | SOFIA: Software and Control Flow Integrity Architecture[END_REF] is an instruction set randomization (ISR) solution that encodes the control flow graph in the encrypted binary. It enables the processor to verify the correct behaviour of the running application.

More generally, it seems that for all sufficiently large pieces of software, we observe the emergence of virtual machines, often called weird machines [START_REF] Dullien | Weird machines, exploitability, and provable unexploitability[END_REF]. The problem with these virtual machines is that security properties usually do not transpose into them: the attacker gains an effective way to bypass countermeasures. To counteract this issue, the most effective technique seems to limit the size and complexity of all the programs.

Presenting some relevant RISC-V instructions. In this section recommendations, we propose to modify the JAL and JALR instructions.

Here is a brief reminder of how these instructions work.

• JAL rd, offset (jump and link): jump to the address given by the offset (sign extended, relative to the program counter (PC)). Put the following instruction address into rd. • JALR rd, offset(rs1) (jump and link register): jump to the address given by the offset (sign extended) applied to the value in rs1. Put the following instruction address into rd.

Same-length instructions only

Variable-length instructions help ROP attacks: the attacker can choose to interpret a part of a long instruction as a short one, giving him more opportunities to find useful instructions in a given piece of code. Additionally, variable-length instructions make possible a new class of errors in case of bad alignment with respect to a given instruction size.

The solution is simple, a secure ISA must only propose samelength instructions. In the case of RISC-V, the C extension must therefore be forbidden.

The cost is the missed opportunity of code size reduction due to the compressed representation (estimated to 25 -30% [START_REF] David | Computer Organization and Design RISC-V Edition: The Hardware Software Interface[END_REF]), as well as the corresponding performance improvement due to increased effective instruction cache size.

Recommendation 4 Same-length encoding

Enforce same-length instruction encoding (forbid RISC-V C extension). This Recommendation 4 allows us to recover two bits per instructions (previously used to encode instruction size).

Recommendation 5 Jump alignment modification

Change the JAL instruction alignment requirement: the J immediate now encodes for a multiple of 4 bytes.

Removing forward indirect jumps

Indirect jumps are at the origin of the biggest defender challenge: decide between valid and invalid control flows. Since an indirect jump can jump to any address depending on a data value, knowing the jump destinations requires to find all possible values. As shown in [START_REF] Gonzalvez | A Case against Indirect Jumps for Secure Programs[END_REF], this task is (provably) not possible. In order to make control flow statically decidable and to make runtime countermeasures easier to deploy, we must forbid forward indirect jumps. This is a simple way to promote a structured control flow at the ISA level. Notably, the recent WebAssembly virtual machine has similar (even stronger) constraints, a controversial feature and the origin of inefficient compiler integration [1].

Recommendation 6 Forbidding forward indirect jumps

Remove the JALR instruction to forbid forward indirect jumps. A mechanism is presented in section 5 to reintroduce safer indirect jumps.

Removing the JALR instructions has several consequences that must be mitigated.

• Dispatcher patterns become costly: we need to add a new DISPATCH instruction as shown in subsection 4.3. • It becomes impossible to transfer the control flow to a different program. This point is dealt with in section 5. • It is no longer possible to return to the instruction following a JAL instruction even if we stored the correct address in a register. In particular, it prevents to simply return from a procedure. Apply Recommendation 7 to enable a RETURN instruction. • There is no possibility to perform a direct long jump. Apply the trick detailed below if you really want to enable long jumps.

Recommendation 7 Returns

For efficient returns from procedures, add a new RETURN instruction. Semantically, the instruction should jump to the instruction following the last executed JAL whose bit 7 was set to 1. In other words, the CPU should implement a call stack. The JAL destination register becomes useless and its freed bits (all but the least significant, i.e. 4 bits) can be used to extend the jump reach. A call to JAL now pushes the return address to the call stack if bit 7 (the least significant bit of rd) is 1. Executing RETURN pops the last address in the call stack and jumps to it.

Implementing the call stack. Recommendation 7 asks for a call stack, and its integrity must be guaranteed. Yet, there are several possibilities to implement it. Here is a proposal.

• Introduce a new register csp (call stack pointer) which is implicitely used by JAL and RETURN. • Introduce a hidden register csp_depth which hold the depth of the call stack pointer, independantly of csp's value. • csp can be read from and written to with a dedicated CSR (control and status register) mapping. • To ensure integrity, a push to the call stack (with JAL) or a pop (with RETURN) must protect and verify the addresses in the stack with cryptography. In this case, if we execute JAL 1, offset at the 32-bit address 𝑎 0 , the following sequence occurs.

• Compute return address: 𝑎 1 = 𝑎 0 + 4.

• We store the encrypted address in memory, taking 64 bits: 𝑀 [𝑐𝑠𝑝] ← 𝐸 𝑘 (𝑎 1 ||𝑐𝑠𝑝_𝑑𝑒𝑝𝑡ℎ), with a suitable encryption algorithm 𝐸 with key 𝑘. This binds the return address to the csp's depth. • csp ← csp+8 (two words increment).

• csp_depth ← csp_depth+1.

To RETURN:

• csp ← csp-8. • csp_depth ← csp_depth-1.
• Decrypt the return address, consumming 64 bits on the call stack: 𝑎 1 ||𝑐𝑠𝑝_𝑑𝑒𝑝𝑡ℎ 𝑣𝑒𝑟𝑖 𝑓 ← 𝐸 -1 𝑘 (𝑀 [𝑐𝑠𝑝]). • Verify the csp match: 𝑐𝑠𝑝_𝑑𝑒𝑝𝑡ℎ 𝑣𝑒𝑟𝑖 𝑓 ==? 𝑐𝑠𝑝_𝑑𝑒𝑝𝑡ℎ.

• If we have a match, proceed with the jump to 𝑎 1 .

Long jumps. By removing JALR, we prevent the possibility to do long jumps, outside of the reach a JAL instruction. The new JAL jump range is ±32 MiB (4 bits taken from the rd register in Recommendation 7 and 1 bit gained from Recommendation 5).

Long jumps can be obtained by, for example, modifying the LUI x0, imm instruction to store the immediate value into a temporary xLJ register. At the next JAL instruction, the jump destination is the combination of the xLJ value and the JAL own immediate value. At the same time, the xLJ value is reset to 0.

But do we really need long jumps? If we implement Recommendation 10, the impossibility to do long jumps is a soft limit on the size of a compartment, which can be a good security property.

Adding a dispatch instruction

Removing the JALR instruction can really impact the performances of dispatchers: when the program must branch to numerous different instructions depending on a data value. Previously, the JALR instruction was used for this, but if we follow Recommendation 6 that is not possible any more. The alternative is the inefficient pattern of cascading branching instructions.

To recover the lost performances, we can, as in [START_REF] Gonzalvez | A Case against Indirect Jumps for Secure Programs[END_REF], introduce a new DISPATCH instruction.

Recommendation 8 Dispatch instruction

Introduce a DISPATCH rs1, imm instruction. Where rs1 is the decision register and imm is an unsigned immediate value that gives a bound to the dispatch. If the DISPATCH instruction is at address 𝑎 0 then the program branches to 𝑎 0 + 4 + 4 * 𝑟𝑠1 if 𝑟𝑠1 < 𝑖𝑚𝑚. If 𝑖𝑚𝑚 ≤ 𝑟𝑠1, then the program branches to the "error" address 𝑎 0 + 4 + 4 * 𝑖𝑚𝑚.

HARDWARE SECURITY CONTEXTS

The microarchitecture has been shown to be the source of numerous information leakages. In 2005, Bernstein [START_REF] Daniel | Cache-timing attacks on AES[END_REF] proposed a technique to exploit cache timings to recover an AES cryptographic key. He showed how the key can be deduced from the timings of array lookups. Later, Percival showed in [START_REF] Percival | Cache missing for fun and profit[END_REF] that since different hardware threads share the same cache memory at some level, it becomes possible to spy on one thread from another one. They were the first to reveal the isolation issue at the hardware level. Unfortunately, this problem was not taken seriously and was even amplified by the addition of multiple performance-oriented mechanisms directly exploiting shared information (speculation, branch prediction . . . ). Finally, this led to the publication in 2018 of the famous Spectre [START_REF] Kocher | Spectre Attacks: Exploiting Speculative Execution[END_REF] and Meltdown [START_REF] Lipp | Meltdown: Reading Kernel Memory from User Space[END_REF] attacks, but also of their multiple variants [START_REF] Canella | A Systematic Evaluation of Transient Execution Attacks and Defenses[END_REF][START_REF] Minkin | Fallout: Reading Kernel Writes From User Space[END_REF][START_REF] Schwarz | ZombieLoad: Cross-privilege-boundary data sampling[END_REF][START_REF] Van Schaik | RIDL: Rogue In-Flight Data Load[END_REF] showing that the whole modern microarchitecture is impacted.

Vulnerabilities on devices of multiple manufacturers [START_REF] Kocher | Spectre Attacks: Exploiting Speculative Execution[END_REF][START_REF] Lipp | ARMageddon: Cache Attacks on Mobile Devices[END_REF][START_REF] Moritz Lipp | Take A Way: Exploring the Security Implications of AMD's Cache Way Predictors[END_REF] have shown that the isolation issue is not just the result of poor implementation choices, but is a deeper problem that requires rethinking the architecture. Depending on the executed application, we need to make the software able to send specific security informatio to the hardware. But it also has to preserve the basic abstraction role of the ISA, by keeping a clean and simple interface.

The problem of leaky abstractions

Considering security, from the software point of view, the abstraction provided by current ISAs can be a real burden. If it greatly simplifies the functional vision of the system, it does not take into account the multiple physical phenomena or other artificial mechanisms exploited by attackers.

Timing variations, fault injections or speculation mechanisms are all existing possibilities on the hardware side but totally hidden on the software side. Current software is completely blind to threats targeting the microarchitecture since they are out of the scope of the ISA's semantics.

One way to solve this issue is to radically change that by adapting the ISA to give it the full responsibility of hardware micromanagement as proposed in [START_REF] Ge | No Security Without Time Protection: We Need a New Hardware-Software Contract[END_REF]. Dedicated instructions can be added to be able to flush independently cache memories or prediction tables, create speculation barriers etc. However, if this represents an interesting approach in the short-term to be able to patch the system at any moment (the way that the software manages the hardware can be easily changed by modifying the code), it represents a dangerous approach in mid to long-term.

Modern CPU microarchitectures can be extremely heterogeneous, from a very simple pipeline to multithreaded cores with many different performance-oriented mechanisms. First, managing hardware security at the software-level involves being able to support all these different cases with the ISA. For that purpose, each mechanism must have dedicated instructions, which totally breaks the abstraction role of the interface. The final result of this approach is that software must be designed depending on the targeted microarchitecture. Each future target change will require more or less significant modifications to be secure: portability of secure application becomes impossible. Second, considering the whole system security (both hardware and software issues) only at the software-level directly impacts the code size. Increasing the software complexity opens the way to more mistakes by developers. In addition, the new micromanagement instructions offer new possibilities for the attackers, increasing the attack surface.

Finally, a clean interface between hardware and software helps to simplify security problems, potentially allowing automatic verification of security properties. From that point, we can deduce the following recommendation.

Recommendation 9

No micro-architecture management Forbid all micro-architecture management instructions, cache management in particular. However, it is clear that we must have a tool to guide these micro-architectural operations. We introduce now a new way to talk about security in the ISA by using an implementation-independent concept.

Managing security domains with HSCs

We call hardware security context (HSC) a domain where all executed operations respect the rules associated with this domain. These rules define a security policy which deals with different properties: isolation, confidentiality, integrity etc.

The notion of security policy is essential to be able to efficiently design secure applications: it gives an implementation-independent information to the hardware. And since a security policy is an abstract concept usable by the software independently of how it is really implemented, a liberty of implementation is granted to the hardware developer.

At the ISA level, these security policies are defined with instructions. From this analysis and the previous leaky abstraction issue, we can deduce one more recommendation about microarchitectural guarantees:

Recommendation 10 HSC instructions

Micro-architectural security guarantees must be provided through the HSC instructions described in this section.

RISC-V HSC extension proposal

This proposal can be seen as an extension over our base RV32S ISA.

Single hart.

We consider the simplest case where only one hart (also named hardware thread) is available for the whole system. Therefore, for the software, there is only one HSC at a time.

HSC data structure. Each HSC is composed of at least two pieces of data: a cryptographic key and an entry point. The key is generated, managed and used by the hardware and never directly accessible by the software. It is used as the HSC identifier: two HSCs with different keys are different and must be isolated. The entry point represents the only program counter (PC) allowed to enter the corresponding HSC.

Additional data can be added to this structure. To illustrate such a use case, we add a capability register where each bit corresponds to the ability to perform or not some operations in the given context, as shown on Table 1. On the same model, other data could be tied to the HSC: more capabilities, memory ranges etc. During execution, these data structures are locally stored in dedicated registers: we call them HSC configurations (or hscconf). As an example, we arbitrarily consider that we have only two hscconf registers available. Each hscconf is composed of the same three pieces of data described previously: key, entry point and capabilities. The first register, hscconf0, corresponds to the properties of the currently executed HSC. The properties of an HSC cannot be changed during its execution: hscconf0 is read-only. The other hscconf1 register defines an HSC that can be modified with the adequate rules and switched to.

Accessing and modifying a hscconf register. First, HSCREAD rd, hscconfs1, offset is used to read a value inside configuration register hscconfs1 with offset defining the specific element of the data structure (e.g. 1 for key, 2 for entry point or 3 for capabilities). The key must not be directly accessible by the software. To still be able to identify it, a 32-bit hash of the key is returned instead of the key itself.

Different instructions are then used to modify the configurations. HSCGENKEY hscconfd is used to generate a new key, with hscconfd different from 0. After that operation, the hscconfd register is also tagged as new: it is writable. Its capabilities are set with the same value as the current capabilities in hscconf0 and can only be reduced.

HSCWENTRY hscconfd, rs1 is used to change the entry point of a configuration tagged as new: rs1 contains the corresponding address. Lastly, HSCWCAP hscconfd, rs1 is used to modify the capabilities of a configuration tagged as new: rs1 contains the capability values that are verified against the current context capabilities. A register is no longer new when it is stored or a switch occurs.

Storing and loading. The number of different existing HSCs in the whole system is not fixed and can be very important: all the HSC data configurations cannot be simultaneously contained in registers. We need to be able to perform specific memory accesses to store and load HSC data. HSCSTORE hscconfs1, offset(rs1) is used to store an HSC in memory, at address rs1+offset.

In the same way, HSCLOAD hscconfd, offset(rs1) is used to load an HSC from memory. Because the memory alone is not a safe place to store sensitive data, some measures must be implemented to ensure that loaded configurations from memory are valid and have not been modified. Different strategies are possible: dedicated memory range to store HSCs, memory access control, stored data encryption using the HSC key . . . Context switching. Finally, we need to change the current executed HSC: we can introduce HSCMV hscconfd, hscconfs1 . This instruction is used to transfer all values contained in hscconfs1 to hscconfd. Both HSCLOAD and HSCMV are able to switch the context by modifying the hscconf0 register when hscconfd = 0. During an HSC switch, the different hscconf registers are not cleared, so they can be used to transfer HSC data to the next HSC. Another new register, prevhsc , can be used to automatically store the 32-bit hash of the HSC caller key. Now, assume we want to create a new HSC and switch to it. hscconf1 is used to configure it, x1 contains its entry point and x2 its capabilities. A possible code sequence is

• HSCGENKEY hscconf1 to generate a new key.

• HSCWENTRY hscconf1, x1 to write the entry point.

• HSCWCAP hscconf1, x2 to set the capabilities.

• HSCMV hscconf0, hscconf1 to switch to the new HSC.

Multiple harts and cores.

Modern systems are a bit more complex than a simple hart running: they can be numerous, distributed within several cores. We consider here a static model where an HSC, to safely execute more instructions simultaneously, have to explicitly request it. Then, the hardware has to verify that this request is possible, depending on the security policy. We need to introduce a notion of parallelism to correctly use all the available resources. For that purpose, we introduce two new instructions for HSC management which assume that all resources are interconnected and support HSC.

HSCSTART rd, hscconfs1 is used to create a new instance of the HSC in the hscconfs1 structure by launching it in a new concurrent hart. This instance can be launched anywhere at the hardware-level, depending on the implementation, as long as its security policies and capabilities can be used there. The necessary resources are then statically allocated and associated to the corresponding HSC. If the operation is possible and successful, then rd = 0 else rd = 1. As a complement, HSCEND rd is used to end the current hart. It allows to statically release resources owned by an HSC, making them available to execute a hart with another HSC. If the operation fails, then rd = 1 else nothing happens due to the HSC termination.

These two instructions deviate significantly from the traditional approach of having always-on harts. But in the post transient execution attacks world, that is not possible anymore. The only other possibility is to forbid resource sharing for different HSCs, simultaneous multithreading becomes impossible if it involves more than one HSC.

Secure property extension.

Naturally, HSC support provides all the needed information to allow isolation: each executed instruction or data handling is performed in an HSC. The implementation must ensure that clear barriers between the HSC are respected at the hardware-level. But more importantly, HSC support provides interesting tools to ensure other security properties.

To offer privacy of an HSC, the key provided by each one can be used to encrypt all code and data stored in memory. It ensures that only an HSC, with its key, can access this information. In section 4, we talked about CFI issues and why we need to banish indirect jumps. HSC support offers a secure alternative with the possibility to create a new HSC with a particular entry point before switching.

CONCLUSION

In this position paper, we propose to modify the ISA in order to offer strong security guarantees. With the introduction of hardware security contexts (HSCs), we have an ISA isolation primitive that both hardware and software can rely on. Furthermore, we can use HSCs to build other protections such as restricting indirect jumps to HSC switches, or binding confidential data to an HSC using confidential registers.

Work is needed to validate the different proposals and to precisely understand the underlying trade-offs, in particular for the micro-architecture, for the compilers and operating systems.

Table 1 :

 1 Operations on HSC configuration data structures

	Configuration	hscconf0	hscconf{1..+}
	Key	Return hash	Return hash | Load | Generate
	Entry point	Read-only	Read | Load | Write new
	Capabilities	Read-only	Read | Load | Write less

ACKNOWLEDGMENTS

We thank the Direction générale de l'armement (DGA) for its financial support.


Le Lay

Alfonso - Lizarazo

Bongue, Célarier, Gonthier, Masmoudi Xie Augusto

INTRODUCTION 1.Context

The management of key resources in healthcare centres has become a crucial matter for decision makers of the hospital. In particular, the bed occupancy ratio of a service is a useful performance indicator for the hospital. It is essential for caregivers to keep a small number of beds available to address emergencies while having too much unoccupied bed shows that the service is in overcapacity. A relevant management of beds will also have advantages for the patient, as it will improve the quality of care at the hospital and reduce the inpatients mean waiting time. The number of unoccupied beds to keep is the element in which management can rely to be responsive when unexpected events occur, such as the failure of a key device, or the departure of a surgeon. Other factors can impact the hospital attendance, like seasonality (epidemics such as flu in winter or heat waves in summer) or more persistent factors like the ageing of the population.

Before defining those figures it is essential to have a mid-term vision on the patients attendance to the hospital. The administration staff of the hospital needs to know the number of beds required to state on annual closing of beds during holidays or on the exceptional opening of extra beds for emergent patients. Industrial engineering and operational research approaches have been widely used to predict bed occupancy in hospital, and Discrete-Event Simulation (DES) have proven useful to manage resources in a process analysis. In this paper, we describe the development of a DES tool designed to predict bed occupancy ratios for a healthcare center taking into account the history of patients' attendance over the past years and predictions of future arrivals.

Related Work

The analysis of patients' stays in hospital is extensively covered in the literature. Predicting the attendance in a healthcare delivery structure allows managers to become proactive regarding resource management decisions. Forecasting models like time-series have been developed by [START_REF] Farmer | Models for Forecasting Hospital Bed Requirements in the Acute Sector[END_REF] to give health service planners this opportunity. Numerous analytical models were designed as decision support systems. For instance short-term bed occupancy can be predicted using autoregressive integrated moving average according to [START_REF] Abraham | Short-Term Forecasting of Emergency Inpatient Flow[END_REF]. Regression techniques also give good results [START_REF] Kumar | Predicting Bed Requirement for a Hospital Using Regression Models[END_REF] when predicting short-term bed demands for several classes of beds. Similarly [START_REF] Tan | Data-Driven Decision-Support for Process Improvement through Predictions of Bed Occupancy Rates[END_REF] implemented Principal Component Analysis and Multiple Linear Regression methods to alert an Emergency Department (ED) of bed crunching risk on the short-term.

Beyond analytical prediction, simulation models have proven to be useful for modelling the patients' flow and a decision's impact on a healthcare system. For instance, queuing networks have been used by [START_REF] El-Darzi | A Simulation Modelling Approach to Evaluating Length of Stay, Occupancy, Emptiness and Bed Blocking in a Hospital Geriatric Department[END_REF] to understand the behavior of bed blockers in a geriatric department. Complete hospitals models are quite rare and researchers often focus on a department in particular. For instance, [START_REF] Chavis | A Simulation Model of Patient Flow through the Emergency Department to Determine the Impact of a Short Stay Unit on Hospital Congestion[END_REF] studies the impact of a post-emergency unit on ED patient's length of stay. Indeed, EDs are probably the most studied department using simulation. A review done by [START_REF] Salmon | A Structured Literature Review of Simulation Modelling Applied to Emergency Departments: Current Patterns and Emerging Trends[END_REF] counts 254 journal or conferences publications and thesis using simulation to model ED between 2000 and 2016, with DES being the most used technique. Other techniques, like system dynamics (SD) or agent-based modelling (ABM) are more used when considering the interactions between ED and exterior factors. [START_REF] Cabrera | Optimization of Healthcare Emergency Departments by Agent-Based Simulation[END_REF]) modelled a Spanish ED with ABM to better characterise the operations of a complex system and [START_REF] Chong | Patient Flow Evaluation with System Dynamic Model in an Emergency Department: Data Analytics on Daily Hospital Records[END_REF] uses SD for its ability to account for the complex behaviour of such a service. However, when looking at the whole simulation area, [START_REF] Brailsford | Hybrid Simulation Modelling in Operational Research: A State-of-the-Art Review[END_REF] notes that models combining different techniques are becoming more and more popular.

Building a model of the hospital as a whole is a challenge. The model proposed by [START_REF] Ben-Tovim | Hospital Event Simulation Model: Arrivals to Discharge-Design, Development and Application[END_REF] simplifies the hospital's organisation to do so. The authors grouped together the ward into one unit, and did the same with surgical theatres. In [START_REF] Busby | Data-Driven Generic Discrete Event Simulation Model of Hospital Patient Flow Considering Surge[END_REF], DES is used to detail the links between ED, inpatients wards and surgical theatres. Such models are conceived to be generic and applicable to many hospitals.

Objective and Scientific Contribution

The objective of our work consists in proposing a decision-aid tool for hospital managers, allowing them to decide on the bed requirements for all medical units of a given hospital on a medium term horizon, using past hospitalization data such as medico-administrative data. The main contribution consists in the development of a data-driven DES model, allowing the user to test different resource scenarios and observe their consequences on bed occupancy prediction. The prediction of arrivals and length of stays will be done analytically and then passed to the simulation model. This model can be set up in different ways, to visualize the departure of a key resource at a precise time like the retirement of a surgeon, or a sudden influx of patients due to an unexpected epidemic. The scientific challenges are twofold:

• The model should consider all medical units: such tool is relevant if patient transfers are taken into account.

• The model should be fed with patient traces extracted from hospital data history to take into account patient's journey complexity. To do so we use a data mining approach to extract past patient traces that will be replayed in the model.

This paper is organised as follows. In Section 2 we present the modelling approach to create the forecast log and the simulation model. In Section 3 we present the results of the different experiments we ran. The analysis regarding those results are detailed in Sections 4. Conclusions and perspectives are given in Section 5.

MODELLING APPROACH

Modelling Hypothesis

The main objective of this paper consists in providing a simulation-based decision aid tool for hospital manager. This tool will help decide on bed allocation in a medium term horizon (next few months). The following hypothesis are taken into account:

• H1: A macroscopic model of the hospital is used. The lowest level of detail is the stay in a medical unit by a patient. To that extent, the patient journey in the hospital is modelled as a trace of stays in different medical unit between his/her admission and his/her discharge. Peripheral activities, such as transfers, tests and surgeries, are not explicitly modelled. • H2: We consider staffed-beds for resources. Each medical unit of the hospital has a predefined number of staffed-beds available. Human resources requirements are extrapolated from bed requirements. • H3: We consider that patients spending less than a day in a medical ward are not occupying a bed.

Indeed our main data source gives the length of stay of patients in days, causing wards with a low mean length of stay to be very easily overcrowded.

This model considers two main sources of patients:

1. Elective admissions patients. These are the patients already scheduled in the next few months. 2. Non elective and emergent patients. Such patients are admitted through the Emergency Department (ED) of the hospital, or directly in a medical unit under recommendation of the general practitioner or emergency services (e.g., Covid patients who are directly admitted in dedicated units).

For elective admissions patients, the model is fed using available data in the information system of the hospital. For non elective patients, we do not have any information apart from the previous admission. To model such patients, we build a case-mix of previous emergent patients and pick up randomly patients in this case-mix.

Le Lay, Alfonso-Lizarazo, Augusto, Bongue, Célarier, Gonthier, Masmoudi, and Xie

Formal Model

Patients

We decided to divide the admissions into 2 groups: (i) patients admitted directly into a ward, and (ii) patients admitted through the Emergency Department. We considered patients of the first group as being "planned" by the hospital: although their origins are varied, direct admission show that these pathways are under control. On the other hand, patients admitted through the ED are managed on the run and the medical staff is reacting to their pathologies. The information available through the patient record are the following:

• Anonymous patient identifier, • Wards in which the patient have been admitted, • Date of admission in each ward, • Length of Stay (LoS) in each visited ward,

• Admission modalities and provenance.

From this we computed each patient's trace in the hospital, defined as the chronological succession of wards visited by a patient during his stay at the hospital.

We divided the available data in two subsets, patients admitted to the hospital through the ED (urgent patients), that we will be referring to as Data-set 1, and elective patients, similarly Data-set 2. We used those data-sets to compute several inputs for our simulation.

Medical Units

Medical Units (MU) are modelled as agents and their characteristics as parameters. Two kinds of parameters are used: constants giving information about the existing MU such as the capacity of the ward, and variable parameters used to keep track of the bed and staff demand. When a patient is admitted to a new ward, the ward's occupancy is incremented. The needed staff -doctors, nurses, and caregivers -is calculated by multiplying the occupancy by a theoretical ratio. Those ratios are given by a classification of wards established with health professionals.

Hospitalization Process Model

In our process, we use different sources for each patient type (elective and urgent). Following our hypothesis H1, the model is macroscopic, thus all medical units are modelled by a single delay block on AnyLogic. The only exception to this rule is the Emergency Department, which is placed after the urgent patient source. The patient is routed again to the unit's block if his stay is not finished, creating a loop on the medical unit block. When the stay is over, and all the medical units constituting the trace have been visited, the patient is discharged.

To account for the limited number of beds available, we designed a queuing process. A list of similar services was conceived for each unit. If the medical unit needed by the patient is full, we try to reroute the patient toward these services. The patient waits until a bed is available in a suitable unit. If no bed have been found after a week in the targeted services, the patients is routed to an unoccupied bed in a randomly chosen ward. This abusive choice is made in order to avoid the simulation from being blocked by an endless accumulation of patients. In similar situations, doctors would change the patient destination to ensure the care.

A poll of traces followed by emergency patients admitted during the first semester was created using the Data-set 1. This poll is used as a basis for the admissions of generated urgent patients, each generated agent will be randomly assigned a trace from this poll. We calculated admission rates for each day of the week from the daily number of admission in 2017/2018.

In the final version of our model, planned admissions will be entered in the simulation from the hospital's information system. However in the experiment presented here, we used the 2018 patients in Data-set 2 to create the elective patients' admission log.

EXPERIMENTS AND RESULTS

Our objective is to assess the efficiency of bed-allocation policies in response to predefined situations. After assessing the consistency of the model with the hospital normal activities, we will consider two different scenarios. An increase of arrivals through the Emergency Department and the sudden arrival of patients positive to Covid-19. The Covid+ patient pathway is described here-under.

Case Study

This project is a collaboration with Saint-Étienne's University Hospital (CHUSE). This hospital is composed of 1,795 hospitalisation beds, in 60 departments, located on 3 different geographical sites across the city. It is also the heart of a large territory healthcare network (Groupement Hospitalier de Territoire Loire in French). This large group of healthcare centres is designed to pool the hospitals' resources and facilitate the coordination of care inside a territory.

In this study we excluded the paediatric sector as it is managed independently from other services. The main preoccupation of the hospital is the prediction of the bed demand on the medium term, which could help to predict the impact of unexpected events or policies on bed occupancy levels.

Our objective with this simulation is to provide the hospital with a decision-aid tool. Nowadays, decisions of bed allocations or seasonal bed reductions are based on experience, demands from medical wards or financial perspectives. This visualisation tool will allow the hospital to centralise admission previsions and see how these policies impact the patient's flow. In the actual context of pandemic, we decided to focus on recovery and intensive care units that are facing an unpredicted surge of patients.

Parameters of the Studied Hospital

The layout of the model is displayed in Figure 1. We used four independent sources to generate patients. ED and MU are modelled by delay blocks, the occupancy of each ward is calculated by incrementing the corresponding parameter.

As explained in 2.2.3, two sources generate urgent and elective patients. ED LoS is modelled by by triangular distribution with a mean of 6 hours. Elective and urgent patients are served by the same MU block. LoS for each patient is calculated with probability distributions specific to the ward. Using Arena Input Analyzer software we fitted probability distributions and the corresponding parameters for each MU.

Another source is generating warm-up patients. All patients admitted to the CHUSE in 2018 and still present on the 1st of January 2019 are generated using this source to initialise the simulation. Pathways and lengths of stay in each MU are directly used in the simulation. These patients go through a MU block with fixed LoS passed as patient's parameters.

The last source generates Covid-19 patients. Their pathway is fixed, they are admitted to the general recovery unit after a short ED stay. The LoS in this MU is determined by a normal law with a 12 days mean and a standard deviation of 3 days. This is a rough approximation based on discussions with professionals and preliminary data. 10% of the patients are discharged to account for in-hospital mortality. Others are redirected to an intensive care units for a similar time. We consider that after this ICU stay, the patients are discharged from the hospital.

Data

The data was extracted by the Department of Medical Information of the CHUSE. It includes all patients admitted to an adult care unit and discharged during the years 2017 and 2018. We also have the daily bed openings in 2018 for each ward to complete the model.

We used the data (Santé Publique France 2020) regarding patients admitted to a recovery unit in the Loire department for coronavirus with respiratory complications from 03/18/2020 to 04/20/2020. We decided to set the upper bound for arrival rate to 10 patients per day. To simplify and simulate a short epidemic outbreak, Covid patients arrival is programmed from 03/18/2020 for 2 weeks before being set back to 0.

Design of Experiments

We ran different experiments to test the simulation model summarized in Table 1. First we tested the model with real data by using the available log on 2017/2018. This validation scenario will be run with infinite capacities, Scenario 0, and finite capacities, Scenario 0'.

A second set of experiments (Scenarios 10-43) is proposed to study a daily admission rate increase. We used our generated data predicting the attendance on 2019 with a varying arrival rate of urgent patients. According to [START_REF] Bergonzoni | Les Etablissements de Santé -Edition[END_REF], ED attendance in France has annually increased by 3.5% on average since 1996. Thus we decided to consider 4 ED admission rates (observed average, 1%, 3%, 5% increases).

Experiments will be run with infinite and finite capacities to see the impact of the rerouting possibilities on occupation indicator. Then we will redefine the MR capacity to 90% and 110% of the mean occupation of the finite capacity scenario to experiment a sizing of the ward.

For the last set of experiments (Scenarios 50-54), we extended the simulation to the first semester of 2020 and added the Covid patients outburst. We make set the admission rate of Covid patients to 5 per day for two weeks. Again, we will test this at finite, Scenario 5, and infinite capacities. However, we will allow the entry of Covid patients, even when the ward is fully occupied. We will test two response policies: the rerouting of urgent and elective patients to another ward, and a 25% increase of capacity of the MR ward, independently and combined.

In scenario 0 we consider a 1-year warm-up period (2017). For all other scenarios, the warm-up period of the model is set to 6 months using the warm-up patients described here-above.

Key Performance Indicators

The output variables of the simulation are the mean occupancy ratio of the "Multi-purpose Recovery" (MR) ward and the maximum occupancy over the studied period. The first figure will allow us to compare the global impact of the epidemic on the ward, while the second gives us the maximum amount of resources that are required to face the demand and thus quantify how the service is overwhelmed. Those indicators were calculated over different periods depending on the scenario. In scenario 0 we consider the year 2018, for scenarios 10-43 we consider the year 2019, and for scenarios 50-54 regarding Covid patients, the indicators were calculated between the 01-01-2020 and 06-30-2020.

Results

For each scenario we set 10 replications and calculated the mean and standard deviation of the two KPIs. The results are summed up in Tables 2, 3 and 4.

Validation Scenario

In this scenario we inject history log and compare the output of the simulation with real KPIs. The results in Table 2 show a Mean OR of 83.90%. This result is coherent with the real observed occupation rate. The maximum occupancy in the service is 16. This ward is required by a lot of patients and sudden surges can occur. However doctors and nurses will manage patients pathways to keep the number of patients under the Le Lay, Alfonso-Lizarazo, Augusto, Bongue, Célarier, Gonthier, Masmoudi, and Xie ward's capacity, explaining the small difference between the capacity (15) and the maximum occupancy (16).

Normal Activity Simulation

In scenarios 10, 20, 30 and 40 we notice that mean occupancy ratio is a lot smaller than the one in validation scenario, while the maximum occupancy across the 10 repetitions is higher (see Table 2). We believe this difference may be partly caused by the hypothesis Indeed, this hypothesis may conduce the model to accept patients too quickly into certain wards, thus reducing the global occupation rate in critical services. The increase of admissions through the ED has a small impact on the ward's occupancy, but is still noticeable.

Finite Capacities and Ward Resizing

The results are summed up in Table 3. First, we see that taking into account finite capacities leads to higher occupation rates for the MR ward. We can also notice that the increase in emergency patients arrival does not affect the mean OR enough to have an impact on the wards' target values for our sizing experiment (8 and 10 beds) on such a short period of time. When the capacity is fixed to 8 beds, we can see that the MR ward occupation rate is really close to 100%, leaving no beds available for unexpected patients.

COVID Simulation

The massive arrival of patient logically causes an increase of the Occupancy Rate of the MR ward. At baseline, with a Covid patient arrival rate at 0, the system behaves as expected, with indicators similar to the one of scenario 1. The staff needed to respond to this surge is high as well.

Le Lay, Alfonso-Lizarazo, Augusto, Bongue, Célarier, Gonthier, Masmoudi, and Xie

In Table 4 a daily arrival rate of 5 Covid patients overcrowds the ward, with an average maximum occupancy of 65 patients at the same time. The bed and staff requirements are high, at baseline our medical partner indicates that about 8 doctors and 40 nurses work in the MR ward with 15 beds. Without any action on the admission policy, the hospital would need the equivalent of 5 MR units fully staffed to treat all patients during the pandemics. We can see that the combination of a temporary increase of the capacity and the routing of non-covid patients to other units are significantly reducing the Mean OR.

DISCUSSION

The main contribution of this paper is the conception of a digital twin of a health care centre, able to adequately mimic the behaviour of our partner hospital. We believe that our model can be a valuable decision-helping tool to estimate the resources needed for day-to-day operations and to assess the need for a special policy in the case of unpredicted events as we did in scenarios 50-54.

Although the results of the simulation are promising, we believe this model can be improved, in particular the wards' finite capacities and waiting queues. Indeed the relations between the ward can be more accurately described. For instance, a patient could be rerouted to another ward based on his diagnoses and the wards' specialities for instance.

Moreover, additional work should be done to clean the database and correct the problems posed by hypothesis H3. Indeed we noticed that wards highly demanded for short stays (less than 3 days in average) are not well modelled by our simulation, causing an accumulation of patients waiting for a bed, even in Scenario 0. We believe that obtaining more precise data for those few wards should help improve the model.

Response policies have been designed and tested to test our model. We believe that studying the actual response of the CHUSE to this crisis, with precise data on Covid patients' pathways, would improve this model. In addition, implementing dynamic surge policies, like allowing an admission without considering capacities under certain conditions would greatly improve the model.

CONCLUSIONS

In this paper, we described the creation of a simulation model of the hospital from patients' records. The study of patients' stays allowed us to build a macroscopic and representative model of the studied hospital. We produced a prospective analysis of patients arrivals on the year 2019 and the first semester of 2020. This allowed us to analyse bed occupancy when the hospital is running its usual activities.

Using data from the current coronavirus pandemic, we ran an experiment to demonstrate how this simulation could be used to assess the model's response to an unexpected variation of arrivals. We believe the results demonstrates how this tool can help the decision process concerning bed management policies when facing unexpected events. The strength of this data-driven DES model is its ability to account for the major part of the hospital. In addition, given a thorough data analysis, it can be used to test different organisations of the hospital in what-if scenarios, or applied to other health care centres.

We identified and detailed several perspectives of improvement that will help in providing a robust insight on the hospital current state and reassert its use as a decision-helping tool. First, implementing more realistic patients' pathways will improve the accuracy of the model in describing hospital's day-to-day activities. Secondly, the definition of dynamic surge responses is a necessary step analyze the impact of exceptional crises like Covid-19 epidemic. Once completed and reviewed by hospital's officials, a standalone version of the model is to be delivered as a decision-aid tool.

Figure 1 :

 1 Figure 1: Hospitalization process model representation.

Table 1 :

 1 Details of the experiments considered.

	Scenario	Finite	ED admission rate	MR sizing	Covid Response
		capacities
	Scenario 0	No	-	-	-
	Scenario 0'	Yes	-	-	-
	Scenario 10	No	Observed average	Observed capacity	-
	Scenario 11	Yes	Observed average	Observed capacity	-
	Scenario 12	Yes	Observed average	90% Mean OR Sc11	-
	Scenario 13	Yes	Observed average 110% Mean OR Sc11	-
	Scenario 20	No	1% increase	Observed capacity	-
	Scenario 21	Yes	1% increase	Observed capacity	-
	Scenario 22	Yes	1% increase	90% Mean OR Sc21	-
	Scenario 23	Yes	1% increase	110% Mean OR Sc21	-
	Scenario 30	No	3% increase	Observed capacity	-
	Scenario 31	Yes	3% increase	Observed capacity	-
	Scenario 32	Yes	3% increase	90% Mean OR Sc31	-
	Scenario 33	Yes	3% increase	110% Mean OR Sc31	-
	Scenario 40	No	5% increase	Observed capacity	-
	Scenario 41	Yes	5% increase	Observed capacity	-
	Scenario 42	Yes	5% increase	90% Mean OR Sc41	-
	Scenario 43	Yes	5% increase	110% Mean OR Sc41	-
	Scenario 50	No	Observed average	Observed capacity	none
	Scenario 51	Yes	Observed average	Observed capacity	none
	Scenario 52	Yes	Observed average	Observed capacity	Reroute other patients
	Scenario 53	Yes	Observed average	Observed capacity	Temporary capacity increase
	Scenario 54	Yes	Observed average	Observed capacity	Sc 52 and 53

Table 2 :

 2 Occupancy ratio and maximum occupancy in the MR ward at infinite capacities.

		Mean OR (%) (std dev) Average maximum Occupancy (std dev)
	Scenario 0	83.90 (-)	16 (-)
	Scenario 10	52.19 (1.53)	18.0 (1.63)
	Scenario 20	52.94 (1.65)	18.2 (1.23)
	Scenario 30	54.00 (2.49)	18.7 (1.50)
	Scenario 40	54.48 (2.52)	18.1 (1.52)

Table 3 :

 3 Occupancy ratio and maximum occupancy in the MR ward with finite capacities.

		MR Capacity Mean OR (%) (std dev) Maximum Occupancy (std dev)
	Scenario 0'	15	84.84 (-)	15 (-)
	Scenario 11	15	58.94 (2.00)	15 (-)
	Scenario 12	8	99.97 (0.04)	8 (-)
	Scenario 13	10	88.75 (3.54)	10 (-)
	Scenario 21	15	57.38 (1.51)	15 (-)
	Scenario 22	8	99.95 (0.09)	8 (-)
	Scenario 23	10	91.72 (4.69)	10 (-)
	Scenario 31	15	59.86 (2.25)	15 (-)
	Scenario 32	8	99.98 (0.03)	8 (-)
	Scenario 33	10	92.31 (3.87)	10 (-)
	Scenario 41	15	60.40 (1.83)	15 (-)
	Scenario 42	8	99.96 (0.07)	8 (-)
	Scenario 43	10	91.57 (4.22)	10 (-)

Table 4 :

 4 Occupancy ratio and maximum occupancy in the MR ward with Covid patients.

		Mean OR (%) (std dev) Average maximum Occupancy (std dev)
	Scenario 0	83.9 (-)	16.0 (-)
	Scenario 50	60.8 (1.52)	65.0 (9.37)
	Scenario 51	69.0 (2.12)	63.3 (10.12)
	Scenario 52	67.1 (2.43)	62.5 (9.96)
	Scenario 53	66.2 (1.99)	59.5 (7.06)
	Scenario 54	64.6 (1.96)	61.5 (7.15)

AUTHOR BIOGRAPHIES

JULES LE LAY is currently a Ph.D Student at the Center for Health Engineering at Mines Saint-Etienne, FRANCE. He received a MsC in Engineering from Mines Saint-Etienne, Auvergne-Rhône-Alpes in 2017. His research interests include modelling, simulation and optimisation of health-care systems. His e-mail address is jules.le-lay@emse.fr.