thomuk / despatientpathway

A shiny app modelling hospital patient pathways

Hi, I'm an data analyst manager in the NHS

I believe strongly in:

• The importance of data, analysis, and information for good decision-making.
• Analysis produced using reproducible methods (in the NHS that means R and python, complete with version-controlled code).
• Open-source code. Many pairs of eyes are better than one. Stand on the shoulders of giants (and allow others to stand on yours).
• The power of community. We are all trying to solve similar problems - don't under-estimate the help you can provide by sharing what you already know.

despatientpathway's Issues

Make assumptions clear to the end user

Many are already listed in the readme.

To add:

• Bank holidays are not modelled
• Theatre maintenance is not modelled
• Clinic schedule changes around xmas (if there are changes in addition to bank holidays) are not modelled.

Add a variable to configure OP DNAs

Make NEWS changelog visible from within the app

Add shared pathway for high priority (eg. cancer) patients

Make another set of inputs for priority patients. Arrival rate and LOS options should be separately configurable, but they will share resources with standard priority patients.

Improve visualisation of model results

Currently the model results are visualised using standard functions from the simmer.plot package.
Improve these visualisations to make it simpler to tell the story of the service being modelled.
Keep in mind the need to present the model to:

• Non-technical users who will have no understanding of the DES theory
• Analysts who are more familiar with DES, and who need to be able to understand model performance at a glance.

Improve app layout on narrow and wide screens

Two main improvements to make:

1. Improve the layout of UI controls on a large screen
2. Prevent the charts becoming too large on large screens so that screen prints can be taken of results

Change favicon

The current favicon is the default for golem

Allow multiple model runs, summarising the combined results

Each individual model run gives varying results (as a result of the probability functions which drive patient arrival times, OP clinic outcomes, and ward & theatre stay lengths.

The should be a 2nd "page" within the app which will run multiple iterations of the same config, summarising them with likely ranges queue sizes, and resource consumption (eg. 1st, 20th, 50th, 80th, 99th percentiles)

Create functions to run multiple simulation runs

Partially linked to issue #4, this issue is to create the backend functions which could be used manually, or within the Shiny app.
Issue 4 is to wrap these functions into the app frontend, and provide some visualisation of the results.

Improve visibility of underlying simulation process

The current app works well, but is not easy to understand for a non-analytical user.
Provide visibility of the underlying simulation when the "run" button is clicked. This could be a console window showing the logged patient comments, or similar.

Find a way to enable configuring OP and theatre timetables in the UI

Currently these are hard-coded with 8hrs/day schedules, 7 days/wk. This needs to be configurable in the user-interface.

Revise the parameters for OP appointment outcome

Simplify, by making sure the 3 options sum to 100%:

• Book future followup
• Discharge
• Admit to treatment waiting list

Visualise followup rate

The input parameters allow followup outcomes to be specified for each OP appointment.
Add a visualisation to show the proportion of resulting OP appointments that are new / followup.

Method overview page

Make a page in the app to explain the concept of DES, using animated visualisations to build up understanding.

Simplify model using weekly simulation steps

The current model uses simulation steps of a minute each. This makes scheduling resources complex, because day/night and week/weekend must be modelled, or averaged over with a calculation.

This issue is to alter the simulation to make the simulation unit a week. In this way day/night and weekends are handled inherently. There is not (yet) a use-case for day of week or hour of day modelling.

URL encode the variables, to enable sharing of pre-configured models

Shiny has a way of doing this. Implement it in this app.

Add model config details to plot outputs for clarity

The plot outputs are most useful if they also contain the model configs used to generate them.
Add them to a paragraph above each plot, or to the plot captions.

Enable setting a seed

Optionally set a seed to allow system changes to be studied for identical starting conditions.