A framework to accelerate simulation studies of hyperacute stroke systems

Stroke care has been identified as an area where operations research has great potential. In recent years there has been a small but sustained stream of discrete-event simulation case studies in modelling hyperacute stroke systems. The nature of such case studies has led to a fragmented knowledge base and high entry cost to stroke modelling research. Two common issues have faced researchers in stroke care: understanding the logistics and clinical aspects of stroke care and moving from these findings to an appropriately detailed model. We aim to accelerate studies in this area by introducing a conceptual modelling framework that is domain specific for stroke. A domain specific framework trades-off the wide applicability of a general framework against increased efficiency and reuse to support modelling in the problem domain. This compromise is appropriate when the problem domain is complex, of high value to society, and where the saving in future modelling effort is likely to be greater than the effort to create the framework. We detail the requirements of a domain specific conceptual model and then provide domain specific knowledge to supportmodellers in gaining an understanding of the problem situation, translating this knowledge into selected model outputs, inputs and content in the case of hyperacute stroke. We illustrate the use of the framework with an example based at a large hospital in the United Kingdom. © 2017 The Authors. Published by Elsevier Ltd. This is an open access article under the CC BY license (http://creativecommons.org/licenses/by/4.0/).


Introduction
The inaugural issue of Operations Research for Healthcare identified stroke care as an area where operations research had the opportunity to do much better [1]. In the years following this call to action, there have been a small number of discrete-event simulation (DES) studies focused on the logistics of hyperacute stroke care (e.g., [2][3][4]). This includes a special issue on stroke conceptual model [10]. Current CM frameworks for simulation are highly generalisable. These are applicable to broad classes of systems such as healthcare [11], supply chains [12] and defence [13]; or operations systems in general [10]. The broad nature of these frameworks is both a strength and a weakness. Generic frameworks lack domain specific knowledge on system characteristics to improve both the quality and efficiency of model building. As such they do little to lower the entry cost of researchers into a new complex domain such as stroke. A domain specific CM framework is limited in application to a single domain, such as a particular disease treatment pathway, and is reusable across different studies that tackle problems in that domain. Such frameworks lower the entry cost to a new domain by adding domain specific knowledge to a simulation study. For example, details of system elements, relationships, and solutions.
This article details a reusable domain specific CM framework for DES to support investigation of how pre-hospital and intrahospital logistics affect patient outcomes in hyperacute stroke pathways (HASPs). The treatment problem our framework addresses is large scale, applying internationally with an estimated fifteen million strokes occurring worldwide per year. It is widely acknowledged in the stroke literature that there are large gains in treatment rates and favourable patient outcomes through better organisation of stroke care services. However, traditional healthcare evaluation designs such as Randomised Controlled Trials (RCTs) are failing to make an impact [14,15], while simulation studies have led to a fourfold increase in treatment rates of the real system [6]. Internationally there is an urgent need to set up and optimise many similar HASPs.
Our work therefore provides four contributions. First we derive the requirements of a domain specific framework. Second we provide modellers of HASPs with a common knowledge to efficiently develop their simulation models, thereby seeking to exploit similarities observed in stroke system set-up and the choice of simulation model components. We primarily focus on intravenous thrombolysis although we introduce potential ways to model recent intra-arterial therapy advancements in Section 4.4. Third we illustrate the use of the framework using a real world case example. Last, our CM framework is highly reusable in modelling studies of HASPs and mitigates the technical challenges of model reuse at the coding level.
The remainder of the paper is organised as follows. Firstly we provide the background to treatment of acute stroke. This is followed by a review of simulation and conceptual modelling for stroke care. We then present our domain specific CM framework. We detail steps to understand the problem, set modelling objectives and select model content. The framework is then illustrated using a case study from the UK. The final section discusses the implications of the framework and future work.

Stroke
Stroke is major cause of disability internationally and accounts for approximately 1 in every 9 deaths worldwide [16]. The world health organisation estimates that fifteen million people suffer a stroke each year. The cost of stroke is estimated to be 2%-4% of total healthcare costs worldwide [1]. To reduce the substantial human and economic burdens of stroke, healthcare systems must be responsive to the emergency an acute stroke represents [17].
Stroke is categorised into two types: ischaemic and haemorrhagic. The majority of strokes are ischaemic (∼85%), occurring when blood flow to part of the brain is interrupted due to blockage of an artery by a thrombus (blood clot). The latter type refers to a bleed within the brain.
Stroke treatment pathways can be thought of having three distinct phases: the hyperacute (emergency), the acute and the rehabilitation. The stroke pathway is typically initiated by someone other than the patient who witnesses the onset of stroke or finds a patient with suspected stroke. In this article we focus on conceptual modelling for HASPs -the most time critical phase with respect to treatment options and health outcomes and represents up to the first 4.5 h following symptom onset [18]. Treatment of patients in the hyperacute phase is associated with high direct and indirect cost savings in follow-up phases [19][20][21].

Hyperacute stroke pathways
The hyperacute pathway is focused on identification and treatment of stroke patients suffering an ischaemic stroke. It aims to treat a patient using recombinant tissue plasminogen activator (tPA) within 4.5 h of the onset of symptoms potentially combined with endovascular therapy (EVT) within 6 h of onset. Both tPA and EVT restore blood flow to the affected region of the patient's brain either, by dissolving or mechanically retrieving the clot, respectively. Each minute saved in time to treatment prevents loss of 2 million brain cells and adds over a day of extra healthy life on average [22].
EVT is a recent advancement in stroke treatment, that holds much promise, but is not yet widely available due to constraints in terms of workforce capacity and expertise, and dedicated equipment being available 24/7. As such, tPA remains the dominant treatment. Worldwide use of tPA in stroke lies between 1%-8% [23,24]. This low performance is partly attributable to the limited window of opportunity, i.e., the period of time available for rescuing brain tissue while a sequence of events must occur; each of which are vulnerable to delays. A patient or witness must recognise stroke symptoms, contact emergency medical services (EMS), travel to the hospital, be assessed and then be processed in emergency and radiology departments. Fig. 1 provides an overview of a hyperacute pathway. Critical parts of the pathway are often considered to be the recognition of stroke symptoms, the speed at which EMS are contacted and the availability of a Computed Tomography (CT) scanner to rule out haemorrhagic stroke.
Although there are inherent difficulties in successful implementation of HASPs, there is international evidence that operations can be optimised to treat large numbers of ischaemic stroke patients. For example, hyperacute centralisation in London, [25], intra-hospital process improvement programmes in Finland [26] and Australia [27], and optimised 'chain-wide' communication in Chicago [28].

Simulation studies
In recent years there have been several pioneering modelling studies that have focused on improvement of the HASP or aspects of it. All have applied DES [2,4,5,[29][30][31][32][33]. Table 1 lists the focus of these studies along with the inputs and decision variables explored. There is a significant overlap in all of these studies. For example, all apart from [4] have included some elements of intra-hospital operations such as delays in brain scanning or availability of resources. These studies evaluated alternative prehospital and intra-hospital processes in terms of their impact on cycle time targets, treatment rates and post stroke disability. For example, analysing a 'scoop and run' protocol where the patient is transferred to the hospital with minimal pre-hospital work-up by ambulance personnel [2]; or analysing alternative intra-hospital procedures to ensure patients undergo CT scanning within set time limits [32].

Conceptual modelling frameworks
A conceptual model is a ''a non-software specific description of the computer simulation model, describing the objectives, inputs, outputs, content, assumptions and simplifications of the model'' [8]. Modelling frameworks provide stepwise procedures to identify what is to be modelled [10]. The main differences among CM frameworks concern their intended field of application, scope and process support. CM frameworks tend to address broad classes of systems, like operations systems [10], supply chains [12], health systems [11,[34][35][36], and the military [37,38]. For overviews of modelling frameworks, see [8,39,40] and [41].

Research contribution -towards domain specific modelling frameworks
Frameworks offer clear starting points for defining simulation conceptual models. However, they usually do not support the analyst in addressing modelling needs of a specific industry or area of health. For example, as the Robinson framework [10] focuses on the basic building blocks of any DES model, e.g., activities and resources, a modeller must still spend considerable time interviewing domain experts, observing the system, collecting data and conceptualising domain specific simplifications and assumptions. To date, only a very limited number of CM frameworks are available that address more concrete problems [42,43].
Given the availability of general CM frameworks, a key question is when is developing a lower level domain specific CM framework appropriate. We argue that a domain specific framework is worthwhile under three conditions linked to the scale of the problem domain. First, that the problem is sufficiently complex, in that it requires joint effort from both experts in the domain of interest and modelling in order to tackle it. Second, that the problem is important and of high value to either industry or society or both. Third, that future demand and uptake of the framework is sufficient to warrant the effort to create it. Or in other words when the reduction in future modelling effort is expected to be greater than the effort spent deriving the framework.
The overarching requirement of a domain specific CM framework is to support modelling activities by linking the problem scene, relating to an operations system, and the model scene, relating to an abstraction of the operations system allowing for simulation analysis. Key linkages are illustrated in Fig. 2. Situational knowledge is required to support modellers in understanding a real world problem situation and how this then translates into a conceptual model. This in turn is fed back to the problem scene to allow relevant stakeholders to validate and accept the model. Usually, CM is a highly iterative process: activities are rerun until a model is considered acceptable by all parties. This iteration facilitates debate and communication between the two scenes.

Support to understand the problem situation.
General conceptual modelling frameworks such as Robinson's advocate that the first step in CM is to gain an understanding of the problem situation in order to set study and modelling objectives. At a general level it is difficult to set out specifics of how this is be achieved and hence modellers are often unsupported in this area. A domain specific CM adds domain knowledge in order to increase the efficiency and quality of the study. In effect this provides knowledge about 'what do we need to know'. The following areas are required: details of populations to model; approaches to measure system performance; logical description or diagrammatic representation of system components, and their relationships on a generic level; and details of candidate decision variables that can be used to optimise the system.

Support to select model content.
In order to be reusable a domain specific framework supports modellers by providing knowledge about options for model scope, content, level of detail, when it is appropriate to select each and the trade-offs for doing so. Common assumptions and simplifications are key support mechanisms for modellers.

Support for joint study design.
This activity aims to facilitate participative simulation [44,45]. That is, a model has many users including modellers and individuals who work and manage the domain. In order to enable user understanding and discussion, and foster joint debate and agreement on the simulation conceptual model, the framework must make use of problem focused knowledge and detail on how to link the model scene to the understanding of the problem scene. This includes how to operationalise a range of domain specific response measures; and examples of how to select model inputs from a candidate list in the problem domain.

A domain specific modelling framework
Our framework parameterises and extends the Robinson's [10] simulation CM framework with domain specific knowledge for modelling HASPs. Our proposed extensions are based on recent literature reviews of articles focusing on HASP redesign [3,46], and known simulation studies on stroke systems (see Section 3.1). Information obtained on common HASP elements, the choice of components for modelling these, and response measures adopted by the field is supplemented by the authors' experiences in simulation studies in the stroke domain (see Section 3.1). Table 2 summarises the framework and associated tasks. Table 2 lists four areas of situational knowledge: the study population; current performance; process map of the status-quo; and decision variables for experimentation. Knowledge obtained for each of the four areas is meant to inform modelling activities concerning modelling objectives (Section 4.2) and model content (4.3). For example, the exploration of decision variables provides a list of candidate model inputs, while the detailed process mapping provides the modeller with a list of relevant components to aid selection of model content.

Setting the modelling objectives
Modelling objectives clarify the way a simulation study is meant to support client decision making through analysing various system configurations according to some pre-specified measure of performance. Here system configurations relate to alternative setups of the stroke pathway. Usually, choice of configurations is restricted by, for example, hospital budget, physical space, and regulations.

Selecting response measures and target performance levels
Responses can be split into health (primary) outcomes and logistic (secondary) performance levels. For logistic performance, the key contribution of DES is in analysing the likely treatment volume, speed and distribution of the workload of the departments involved. Treatment volume might be presented as an average rate (total stroke treated with tPA/total no. of discharge strokes) or, to exploit the stochastic results, as a histogram of the likely range that treatment rates may fall into, potentially enhanced as a Measure Of Risk & Error (MORE) plot [47].
The logical and time based results from a DES model can then be used as input parameters to either clinical models of population benefit or a health economic model to understand the longer term cost-effectiveness. Several simulation authors [2,30,48] have opted to use the modified Rankin Scale (mRS) scores at 90 days treatment. The mRS score is a scale ranging from 0 (no disability) to 6 (death). One approach to estimating outcomes is to make use of the number needed to treat (NNT) statistics from 0-90, 91-180 and 180-270 min OTT groups (4.5; 9.0 and 14.1 patients respectively [49]). In these cases the simulation model only needs to count the number of patients treated by OTT group and divide through by the respective NNT. Note that by focussing only on mRS 0-1 results may underestimate the benefits seen in shifts in the other mRS categories. More advanced outcomes might include long term costs of stroke and the impact of increased number of patients treated with tPA along with gains in quality of life [19]. Patient safety, in relation to symptomatic intracranial haemorrhage, is often a concern of clinicians involved in such studies. To date, RCTs have been unable to identify a time dependent effect; however, observational studies hint at a possible relationship [50].
Target performance levels are often straightforward for logistic measures such as treatment rates and ATT. In the UK, for example, the Department of Health sets a thrombolysis target of 10%. International benchmarks might be as high as 30% of all ischaemic stroke [26]. There are several standards for ATT to choose from. For example, Helsinki's world leading standard of a median 20 min [26].

Selecting model inputs
Robinson's framework defines inputs as parameters that can be controlled. Table 2 lists the process to identify model inputs. This is conducted in the problem scene where the modeller acts as a facilitator to aid domain experts articulate candidate decision variables. Selection of model inputs from all candidates takes place • Determine study population: Decide subcategories of the stroke population the study might focus on. Subcategories studied may concern either confirmed or suspected stroke patients, or both.
• Assess current performance of the HASP: Establish key figures concerning the annual thrombolysis rate of the hospital, how fast treatment can be delivered during and outside normal hospital working hours, the numbers of patients arriving within 4.5 h of onset and the proportion of patients where an onset time is recorded. Interpret findings with respect to their relevance for setting the modelling objectives (II).
• Map the current process: Create a starting point for determining model content (III) by building a process map that captures the status quo. Fig. 1 may be used as a starting point, to which relevant (case-specific) detail may be added. Clarify whether and how pre-and intra-hospital processes may differ in and outside of normal working hours.
• Explore decision variables for use in experimentation: Process mapping and the (initial) assessment of HASP's current performance serve as a vehicle to elicit hypotheses about delays and barriers to treatment. These hypotheses are candidate decision variables in model experimentation. Choice of decision variables may be linked to four areas (examples): • Pre-hospital logistics: Regional distribution of stroke services, EMS protocols for providing on-scene care services.
• Processes for identification of stroke patients in the ED: (staff) resources, and protocols enabling a quick identification of stroke patients upon their arrival at the ED by EMS or self-transport.
• Communication between hospital departments: The way information about a suspected stroke from the ED is passed to the acute stroke team (AST), the arrangement of high priority CT scans in radiology, the reporting of brain scanning results back to treating physicians, and protocols for communications with other disciplines in the case of complications. results from a DES model can be used as input parameters to either clinical models of population benefit like the modified Rankin Scale (mRS) scores at 90 days treatment [2,29] or a health economic model to understand the longer term cost-effectiveness.
• Logistic performance (secondary level): Treatment volume might be presented as an average rate (total stroke treated with tPA/total no. of discharge strokes) or, to exploit the stochastic results, as a histogram of the likely range of treatment rates.
• Target levels: Target performance levels may be set on logistic performance such as treatment rates and ATT, possibly using available benchmarks.
• Determine model inputs that underlie experiments concerning alternative configurations of the HASP: Construct experiments that link one or more inputs to decision variables, see I.  Table 3.
• Determine model detail, specifying attributes of model components.
See Table 4 for entity attributes that may be required across a broad range of objectives.
• Specify assumptions underlying model content: Facilitate the interpretation of the model and its workings by making assumptions on the HASP under study explicit. See Table 5 for common assumptions on HASP simulation models.
• Making appropriate model simplifications: Inappropriate model complexity, i.e., model complexity that cannot be explained by the choice of modelling objectives or data variance should be avoided, as it increases modelling efforts and may obstruct interpretation of the model and results of the simulation experiments. Common simplifications of HASP simulation models can be found in Table 5.
right at the interface between the problem scene, and the model scene.
As an example, consider the study in [2]. In the problem scene Lahr and colleagues worked with neurologists and the medical director of the emergency ambulance services to establish that on scene pickup time was lengthy and involved several non-value adding activities (in terms of patient treatment). The modellers then worked with domain experts to select an alternative on-scene protocol and closely define how this would be coded in the model.
Follow-up work to [30] provides another example of selecting candidate model inputs. A hospital in the UK struggled to treat any stroke patients within time constraints. Domain experts focussed again on pre-hospital issues, including both on scene and transport time; hypothesising that patients were not arriving in time for treatment and that these inputs should be selected for experimentation. A simple initial analysis illustrated that 18%, 25% and 32% of all stroke patients were arriving within 90, 120 and 180 min respectively. A review of clinical data revealed that up to 10% of all stroke patients should be treatable within a time constraint of 4.5 h. As such, the pre-hospital inputs were deselected. The focus shifted to intra-hospital inputs such as access to CT scanning and the handover between emergency ambulance services and the ED.

Determining model content
In determining model content a distinction is made in (i) model scope, identifying model boundaries, by either including or excluding a representation of elements of the system under study as model components, and (ii) model detail, specifying attributes of model components. Choice of model scope and detail builds on assumptions and simplifications. Assumptions capture beliefs or uncertainties about system elements, whereas model simplifications are meant to reduce the complexity of model development and run time without affecting model validity [8].

Model scope
For capturing model scope Robinson's framework includes four classes of component types: entities, activities, queues, and resources. We adapt Robinson's framework for HASP modelling. The framework is extended to break activities into pre-hospital and intra-hospital to improve manageability. Table 3 lists the most common components, from the published literature, that should be considered in conceptual modelling of the pathway between onset of symptoms and treatment. No queues are specified in Table 3. In principle, any activity can be linked to a queue. Entities represent movable system elements or flows. In HASP models entities are temporary and represent patient flow through a process. For example a stroke occurs, is treated (or not) and exits. If required, patient classification is operationalised as an attribute. Common patient classes include ischaemic strokes, haemorrhagic strokes and suspected strokes.

Model level of detail
Each of the components listed in Table 3 can be modelled at different levels of detail in terms of its attributes. For example, treatment activities might be characterised in terms of their cycle times and diagnostic activities. See [10] for a standard template for attributes. We provide guidance in Table 4 which focuses on entity attributes that may be required across a broad range of objectives. Caution should be taken in selecting the level of detail. For example, it is arguable that the severity of a stroke, indicated by a clinical measure such as the National Institute of Health Stroke Scale (NIHSS), may affect cycle time of certain clinical activities. However, the likelihood of having sufficient data to obtain reliable estimates of such parameters is low and hence an increased effort is required in order to quantify the uncertainty in model performance. Inclusion of a large number of patient attributes also raises issues of dependence.

Common assumptions
There are a number of standard assumptions that simulation models of HASPs make concerning treatment times and priorities. These are summarised in Table 5.
The first is to assume that ATT is independent of OTA. There is evidence that ATT is, in fact, negatively correlated with OTA [48]. This means that intra-hospital cycle time is shorter if a patient arrives with 30 min remaining compared to if they had arrived with 120 min remaining. This deadline effect is straightforward to model at the ATT level. However, in a single hospital study it is unlikely that sufficient data will be available to model at a process level. In absence of data modellers often assume that it is not present and acknowledge it as a limitation.
In order to treat patients within time constraints, hospitals have to prioritise stroke patients over non-stroke patients for a number of resources, for example, medical imaging. Although difficult to verify empirically, a safe assumption is that patients who arrive within four and a half hours of onset of symptoms queue jump for resources when they have been identified as suspected stroke.
Turning to clinical assumptions modellers should be aware that there may be some dependence between patient attributes. For example, positive correlation between age and stroke severity. Severe strokes are potentially more obvious and hence witnesses contact EMS earlier while lower severity cases might self-present or contact primary care services in the first instance. These associations are extremely difficult to quantify. Models often assume independence of attributes in the absence of evidence to the contrary. The importance of this assumption depends on level of detail in the model. For example, if stroke severity and patient age are being explicitly considered as factors that affect model logic, planning will be needed to evaluate if dependence affects performance.

Common simplifications
Stroke patients are often processed within an ED. The queueing time of stroke patients can be accurately modelled with a detailed ED model (e.g., [51,52]); however, even in large hospitals stroke and suspected stroke numbers are relatively low compared to general emergency patients (stroke patients account for about 1 in every 200 arrivals in the ED department, and about 1 in 65 emergency admissions into the hospital). As such it often sensible to simplify ED queueing times to random variables. This reduces model runtime while still providing results of sufficient accuracy. Fig. 1 and Table S1 (online appendix) detail activities within the pre-hospital process. It is only necessary to model this in detail if the modelling objectives of the study focus on the pre-hospital phase. Three levels of detail might be employed ranging from a complex model incorporating resource constrained activities to a simple random variable representing pre-hospital time (see Table  S1 and accompanying explanatory text in online appendix).
Again moving on to clinical factors, common simplifications relate to stroke severity and contraindications to treatment. As discussed in Section 4.3.3, stroke severity may be associated with other patient attributes such as age, time to call EMS or the probability of a contraindication. Modellers need to carefully consider if severity needs to be incorporated into a model explicitly as it may reduce the accuracy of results. One factor in favour of excluding severity from modelling is that the values used to calculate clinical response variables are corrected for severity and hence robust to this simplification.
An important contraindication to treatment is an unknown time of symptom onset. This means that it is not possible to know if a patient can be treated within the safe time window for tPA. Clinical experience reports that rates of unknown onset are higher in morning. This is due to wake-up strokes where a patient has suffered a stroke overnight and has woken up with symptoms. Population studies suggest that 14% of acute ischaemic strokes are wake-up CT scanning C22.
Reporting and interpretation of CT scan C24.
Ambulance paramedic takes patient direct to CT scanner Ambulance paramedic C42.
CT scanners strokes [53]. However, the rates of wake-up strokes by time of day and unknown onset are unclear. As such, a simplification is to keep the probability of a contraindication static and conduct a sensitivity analysis to early morning contraindications.

Potential extensions to endovascular treatment
The most recent developments in acute stroke treatment have been in endovascular treatment (EVT). This is an intra-arterial therapy for individuals suffering from a large vessel artery occlusion [54]. The treatment involves catherization of a patient and use of a mechanical device, e.g., a retrievable stent, to capture and remove the clot from an artery. There are now six positive EVT studies using 3rd generation devices [55][56][57][58][59] in combination with intravenous (IV) tPA. However, there are currently no modelling studies published and it is still too early to establish how this will be implemented in regional stroke care systems around the world. To provide some initial guidance for modellers, we reviewed the protocols of the EVT RCTs. Table 6 lists potential extensions in terms of activities and resources that could be modelled.
Initially it is unlikely that EVT will be available at all treatment centres. This has led to a 'drip and ship' service where patients receive IV tPA at their closest hospital and are then transferred by EMS to a tertiary treatment facility for EVT. As such, single pathway models may need to allow for a subgroup of stroke patients to arrive to an EVT centre pre-treated with IV tPA along with an associated estimate of onset to arrival. Or it may be necessary to model a network of hospitals in detail [33]. Operationally, there may be different time windows for IV and inter-arterial therapies e.g 4.5 h for IV tPA and 6 h for EVT. Recent individually pooled meta-analysis of five of 3rd generation device RCTs provide estimates of time to reperfusion effects [60].

Case example
We now illustrate the framework in Table 7 that we have populated using a case example from the UK [30]. At a high level the HASP setup was similar to that of Fig. 1, but process mapping revealed a more complex picture (see Figure S2 online appendix). It was unnecessary to model all aspects of the HASP in detail and as such they are represented by highly aggregated components. For example, as no relevant model inputs were selected the prehospital phase was modelled at the simplest level depicted in Table  Table 4 Possible levels of detail for entity attributes. Diagnostic test classification Classification of diagnostic results into true/false positives/negatives. Each diagnostic test for stroke has a sensitivity (ability to classify a true stroke correctly) and specificity (ability to correctly identify a non-stroke). Important when modelling arrival rates to an acute stroke unit as false positive patients may spend some time on an alternative ward before identification and transfer. E10 Triage (priority) classification The level of priority given to a (suspected) stroke patient in the emergency department. Used to either reorder patients in a queue or in the case of a Monte Carlo estimate of queueing time alter the choice of sampling distribution.

Table 5
Common assumptions and simplifications for modelling HASPs.

Assumptions:
A1. Activity cycle times are independent of the time remaining until the treatment deadline A2. Patients identified as suspected stroke arriving within 4.5 h of onset of symptoms have priority on hospital resources and queue jump. A3. Independence of patient attributes.
Simplifications S1. Non-stroke patients that share resources in the stroke pathway are excluded S2. ED processes are modelled as a series of random variables without queues (ED activities are not capacity constrained, but include queueing time as a delay) S3. Pre-hospital EMS logistics and network management are simplified to a series of random variables without queues (EMS activities are not explicitly capacity constrained and include queue times) S4. Pre-hospital OTA is simplified to a single random variable. S5. Severity of stroke is excluded. S6. Patients who wake up with stroke and hence do not have an OTA time are not modelled in detail. S1 (online appendix). For a HASP examples where the pre-hospital phase has been modelled in more detail see [2,4].

Discussion
Stroke offers researchers in OR an opportunity to dramatically affect the quality of patient lives. However, given the complexity of stroke treatment and pathways, the entry cost to this domain is high. This paper presents a reusable conceptual framework to flatten the learning curve that new researchers must take to improve the performance of HASPs.  Cross reference entity attributes with Table 4, assumptions and simplifications with Table 5.

Authors reflections on simulation studies of HASPs
The literature of modelling HASPs report well thought out DES models and their results. What is missing and what cannot be communicated within the manuscripts is the sheer complexity of the process of investigation that led from gaining an understanding of the problem through to an appropriately detailed model. As an example, consider the lead author's experience of improving performance of (six) HASPs in the UK. In each case the initial problem structuring and model conceptualisation experience was similar. There was confusion amongst collaborators about the actual performance of the system; processes were presented as idealised worlds as opposed to how they actually operate; political dimensions meant that potential process problems were not initially highlighted by staff; and particularly in initial studies the clinical aspects of stroke and its treatment were difficult to understand by a non-clinician. For those entering the domain the first part of the framework provides a focus and structure for investigation of the problem and clarifying modelling objectives. We also recommend that researchers familiarise themselves with the long running debate about the efficacy of treatment within the neurology and emergency medicine literature [61].
Following gaining a problem understanding there was (and still is) a great temptation to model all processes at a high level of detail. For example, the detailed logistics of the pre-hospital phase including EMS and non-EMS conveyance to hospital are very appealing for an OR modeller to simulate. However, if improvement of the pre-hospital phase is uncontrollable (e.g., call for help times) or not an objective within the study (e.g., in a relatively compact urban area where pre-hospital times are short) then including detail beyond some of the abstract simplifications we describe is unnecessary, expensive and data intensive. On the other hand, the focus of the study might be entirely on the pre-hospital phase. For example, a HASP study focused entirely on experimentation of EMS and call triaging in the pre-hospital phase [4]. In this case, there was no need to model the intra-hospital phase in detail. The second half of the framework provides guidance on selecting content. It is based on the published literature and the combined experience of the authors in HASP modelling. The lists provided are detailed. Not all components will be relevant in each case. However, they prompt modellers to consider their relevancy to meeting study objectives and provide a common language to discuss with subject matter experts and other researchers in stroke modelling.
As elsewhere in healthcare OR, there is a temptation to focus on developing a generic model of a HASP [51]. Both the literature and our experience shows that at a high-level HASP can be described as in Fig. 1. However, such an abstract model has little to offer in terms of identifying alternative workings for a specific hospital. The detail of hospital processes can vary significantly. For HASPs the reusable knowledge is at the conceptual level.

Strengths and limitations
Our work has several strengths. First our framework draws on a strong evidence base, both in terms of published HASP simulation studies and the growing clinical evidence of the link between treatment outcomes and the need for optimised logistics. Second, as our reusable framework is at the conceptual level it can be viewed as a live document that can be extended or refined. This is the first study to consider the extension of HASP modelling to EVT. Section 4.4. is based on a review of the RCTs and provides initial modelling support that will need future refinement.
A limitation of our focus on CM for optimising existing treatment pathways is that we exclude strategic modelling issues concerning the distribution of stroke care services for a region. For example, should stroke care be offered by every community hospital, or should it be concentrated in a few comprehensive stroke centres? Readers are referred elsewhere for an introduction to modelling of multi-treatment centre problems [3,62,63].
Our case study is retrospective and aims to illustrate how components from the framework translate into a full model. It is not intended as a validation of the framework. Further studies that make use of the framework should report potential extensions and refinements.

Lessons and further work
A lesson learnt from this study is that a key requirement of a domain specific CM framework is the linkage between the problem and the modelling scenes. It is now accepted that model building is an iterative process [64]; however, given the general nature of modelling guidance to-date, there is limited support detailing how to move between the problem and model domains. Successful domain specific frameworks must therefore provide some guidance on how to navigate from problem structuring aspects to model creation aspects. For example, translating discussions with stakeholders about controllable decision variables to the selection of model inputs. Moreover, to successfully link the problem and model domains we stress that the simulation team needs to be multidisciplinary in nature.
Further work should identify other types of healthcare that meet the 'need and scale' criteria we set out in Section 3.3. For example, problems faced internationally in emergency medicine. There is a large operational research literature on emergency departments; however, knowledge is fragmented and individual case studies vary in quality and detail and hence provide limited modelling support. Similarly, emergency ambulance services face common logistical problems that could be supported by a CM framework.