Merge pull request #182 from The-Strategy-Unit/169_EARL

Add EARL talk

presentations/2024-09-05_earl-nhp/architecture.mermaid

@@ -0,0 +1,31 @@
+block-beta
+
+columns 5
+
+space space db[("Database")]:1 space space
+
+space:5
+
+space d("Storage: data"):1 space r("Storage: results"):1 space
+
+space:5
+
+i("App: inputs"):1
+space
+m("Model"):1
+space
+o("App: outputs"):1
+
+db --> d
+d --> i
+m --> r
+d --> m
+r --> o
+i --> m
+
+style db fill:#686f73,stroke:#fff,color:#fff
+style d fill:#5881c1,stroke:#fff,color:#fff
+style r fill:#5881c1,stroke:#fff,color:#fff
+style i fill:#f9bd07,stroke:#fff,color:#000
+style m fill:#ec6555,stroke:#fff,color:#fff
+style o fill:#f9bd07,stroke:#fff,color:#000

presentations/2024-09-05_earl-nhp/index.qmd

@@ -0,0 +1,181 @@
+---
+title: "Using R and Python to model future hospital activity"
+subtitle: "EARL Conference 2024"
+author: 
+  - "[YiWen Hon](mailto:[email protected])"
+  - "[Matt Dray](mailto:[email protected])"
+  - "[Tom Jemmett](mailto:[email protected])"
+date: 2024-09-05
+date-format: "D MMMM YYYY"
+format:
+  revealjs:
+    theme: [default, ../su_presentation.scss]
+    transition: none
+    chalkboard:
+      buttons: false
+    preview-links: auto
+    slide-number: false
+    auto-animate: true
+    footer: |
+      Learn more about [The Strategy Unit](https://www.strategyunitwm.nhs.uk/)
+---
+
+## The New Hospital Programme (NHP)
+
+:::: {.columns}
+
+::: {.column width='40%'}
+
+- A manifesto commitment
+- Future activity must be modelled
+- Need consistency across schemes
+
+:::
+
+::: {.column width='60%'}
+
+![](kettering-raac.png){width='100%' fig-alt="The headline of a BBC article that says 'Raac: Top floor of Kettering General Hospital Wing vacated'. There is a picture of the hospital with a caption that starts 'crumbling Raac was discovered in the roof."}
+
+:::
+
+::::
+
+::: {.notes}
+
+- Building new hospitals - replacing crumbling infrastructure in some cases, completely new builds in others.
+- It's important to size the hospitals according to the type and quantity of activity there will be in the future.
+- There are many proprietary black box models in use for estimating healthcare activity in the future - no consistency, difficult to compare results
+- Strategy Unit was asked to develop a model to be used across all of the builds: a model owned and operated by the NHS, for the NHS.
+
+:::
+
+::::
+
+## {#model-process data-menu-title="Model process diagram" .center}
+
+![](nhp-model-diagram-transparent.png){fig-alt='Diagram showing the model flow. We start with baseline activity and capacity, which flows throiugh demand-supply imbalances, demographic and non-demographic changes and finally actitivyt mitigators. The outcome is modelled future activity.'}
+
+::: {.notes}
+
+A probabilistic Monte Carlo simulation that: 
+
+1. Takes hospital activity from a baseline year, using NHS England's Hospital Episode Statistics (HES) data
+2. Applies variables that:
+    + are outside of our control (e.g. population changes, using ONS projections)
+    + can reduce hospital activity (mitigators, e.g. virtual wards or teleappointments)
+3. Forecasts future demand based on these variables, outputting probabilistic predictive intervals
+
+:::
+
+## Our challenges
+
+* 28 hospitals currently using the model
+* Model is being developed whilst in production
+* Model is very complex - technically, and for end users
+
+::: {.notes}
+
+1. Hospitals are actively using the model while it is still in development, which can be tricky
+2. Dataset is massive for each hospital - hundreds and thousands of rows - all activity for a hospital trust in one year
+3. Model can accommodate hundreds of different variables, understanding and setting these can be challenging for end users
+4. We have comprehensive, openly available documentation and also a team of Model Relationship Managers to help address this
+
+:::
+
+## Tools and platforms
+
+* Data pipelines: {targets} {{< fa brands r-project >}}, SQL {{< fa database >}}
+* Model: Python {{< fa brands python >}}, Docker {{< fa brands docker >}}
+* Apps: {shiny} and {golem} {{< fa brands r-project >}}, Posit Connect {{< fa layer-group >}}
+* Infrastructure and storage: Azure {{< fa brands microsoft >}}
+* Documentation: Quarto {{< fa feather >}}
+* Version control and collaboration: Git {{< fa brands git-alt >}}, GitHub {{< fa brands github >}}
+
+::: {.notes}
+
+- So how did we solve the problem?
+- Here's a rundown of the tools and platforms that we use.
+- The data pipeline is orchestrated by {targets} for its recipe-like format and so we re-run only what needs re-running.
+- The model is built in Python and involves a lot of _pandas_ DataFrame manipulations.
+- We use Azure for storage of model input data and JSON files of results.
+- Users input model paramters in one Shiny app and view results in another. This uses modules and {golem} for its package focus, as well as {bs4Dash}. We have development and productino environments.
+- We have a deployed Quarto website that contains the documentation for the whole project.
+- In general, we're following the principles of Reproducible Analytical Pipelines (RAP) in everything we do.
+- All originally written by Tom.
+- As the team has grown we have shared responsibilities: YiWen in Python, Matt with Shiny, Tom as technical lead.
+
+:::
+
+## {#structure data-menu-title="Structure" .center}
+
+![](architecture-mermaid-transparent.png){fig-alt='A diagram showing the architecture of the model and apps. Data is processed from the database by the targets package and stored in an Azure storage account. the model and inputs and outputs apps collected data from there. Selections in the inputs app feed into the model.'}
+
+::: {.notes}
+
+- This is a simplified overview of the structure and flow of information through the system.
+- The full structure is quite complex, reflecting the complexity of user needs and the scale of the task.
+- Data from our database is processed and stored in Azure Storage Containers via a targets pipeline. Additional data, like ONS population projections, are also stored.
+- The users interact with a Shiny app to set their input parameters. The app provides some contextual information derived from the data held in Azure. Users click a button to run the model.
+- The model is deployed as a Docker container in Azure Continer Instances, triggered by an API call.
+- The model results are stored as JSON in an Azure container, ready for collection and presentation in an outputs app.
+- Users can view charts and tables and download files for further analysis.
+- So there's clear front- and backends and we have
+- Further complexity is added by the need to process and present information despite changes to the model over time.
+- We use development and production environments for our apps to help reduce errors.
+
+:::
+
+## {#outputs-app data-menu-title="Outputs app" .center}
+
+![](outputs-beeswarm.png){fig-alt="The NHP Model Results app. On the left is a navbar with a 'home' tab and other tabs grouped under headings of 'results' and 'information'. Users can select individual sites. In the main body is a series of dropdown boxes to select the type of data to show. There's also a beeswarm plot showing the model-run distribution."}
+
+::: {.notes}
+
+- Here's a preview of the outputs app.
+- In the navbar you can see that users can aggregate by hospital sites; view charts and tables; and download results files for further processing.
+- There are also context-specific drodown menus to focus in on certain data. For example, to see results by activity type: inpatients, outpatients or A&E.
+- In this particular tab we can see a beeswarm plot showing each simulation as an individual point. This kind of presentation is important to remind users that the model outputs a distribution; that there are range of possibilities.
+- The data provided here to users is used to drive decisions about the size of hospital that will be developed.
+
+:::
+
+## Next
+
+- Forecast regionally and nationally
+- Move data and pipelines into Databricks
+- Open-source model code
+
+::: {.notes}
+
+- We're currently working with hospitals and trusts, but we're also expanding the geographical scale to produce results at the regional and national scale. This will require some thinking around processing, modelling and generating outputs.
+- We're currently transferring data processing into Databricks, partly to bring all the steps into one platform but also as an opportunity to speed up the processing by using Spark.
+- Finally, we already have some aspects in the open, like the project information site, but we'd also like to open-source the model code itself so that others can use and develop it.
+
+::: 
+
+# Thank you {.inverse}
+
+:::: {.columns}
+
+::: {.column width='60%'}
+
+- Using R and Python to Model Future Hospital Activity: The New Hospital Programme Demand and Capacity Model
+- [YiWen Hon](mailto:[email protected]), [Matt Dray](mailto:[email protected]) and [Tom Jemmett](mailto:[email protected])
+- [The Strategy Unit](https://www.strategyunitwm.nhs.uk/), [NHS ML](https://www.midlandsandlancashirecsu.nhs.uk/)
+
+:::
+
+::: {.column width='40%'}
+
+![](earl-nhp-qr.svg)
+
+:::
+
+::::
+
+::: {.notes}
+
+- So, we've made innovative use of both Python and R together--along with a raft of other tools--to help solve a complex and important issue within the healthcare sector.
+- This QR code takes you to the URL for this talk.
+
+:::