Skip to content

Commit 2a2e018

Browse files
committed
docs(stress): improve 2.3 (#4)
1 parent f58a1ae commit 2a2e018

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

docs/stress_des.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -19,7 +19,7 @@ Answers to this checklist are adapted from [llm_simpy/notebooks/03_stroke/00_str
1919
| **Logic** |
2020
| **2.1 Base model overview diagram**<br>Describe the base model using appropriate diagrams and description. This could include one or more process flow, activity cycle or equivalent diagrams sufficient to describe the model to readers. Avoid complicated diagrams in the main text. The goal is to describe the breadth and depth of the model with respect to the system being studied. | ![Logic diagram](../images/stroke_rehab_design.png) |
2121
| **2.2 Base model logic**<br>Give details of the base model logic. Give additional model logic details sufficient to communicate to the reader how the model works. | The model lets users define populations of stroke, TIA, complex neurology, and other patients, each with their own arrival patterns, transfer probabilities, and length-of-stay distributions for acute and rehab services. It uses an infinite capacity approach to estimate admission delay probability. The design focuses on acute and rehab units, with a warm-up period and multiple replications; ESD pathways are simplified but the model can be extended to include them. |
22-
| **2.3 Scenario logic**<br>Give details of the logical difference between the base case model and scenarios (if any). This could be incorporated as text or where differences are substantial could be incorporated in the same manner as 2.2. | Scenarios in the article (increased demand, grouping patient types) are implemented as parameter changes in the notebooks. |
22+
| **2.3 Scenario logic**<br>Give details of the logical difference between the base case model and scenarios (if any). This could be incorporated as text or where differences are substantial could be incorporated in the same manner as 2.2. | Scenarios are defined by changing input parameters (e.g., admissions rates, bed numbers, patient groups) and re-running the model; no code changes are required. All scenarios from the original publication are implemented:<br>・**Base Case:** Default parameter values.<br>・ **Increased Demand:** 5% higher acute admissions.<br>・ **Pooling Beds:** Combines/reallocates bed numbers between acute and rehab units.<br>・ **Patient Group Removal:** Runs without complex neurological patients to isolate impact. |
2323
| **2.4 Algorithms**<br>Provide further detail on any algorithms in the model that (for example) mimic complex or manual processes in the real world (i.e. scheduling of arrivals/ appointments/ operations/ maintenance, operation of a conveyor system, machine breakdowns, etc.). Sufficient detail should be included (or referred to in other published work) for the algorithms to be reproducible. Pseudo-code may be used to describe an algorithm. | There are no algorithms used in this model. |
2424
| **2.5.1 Components - entities**<br>Give details of all entities within the simulation including a description of their role in the model and a description of all their attributes. | ・ Stroke<br>・ Transient Ischemic Attack (TIA - minor strokes with rapidly resolving symptoms)<br>・ Complex Neurological<br>・ Other (including medical outliers) |
2525
| **2.5.2 Components - activities**<br>Describe the activities that entities engage in within the model. Provide details of entity routing into and out of the activity. | ASU + rehab treatment activities:<br>・ Stroke patients who are eligible for Early Supported Discharge<br>・ Stroke patients who are **NOT** eligible for Early Supported Discharge<br>・ TIA<br>・ Other |

0 commit comments

Comments
 (0)