Using R and Python to model future hospital activity

EARL Conference 2024

YiWen Hon

Matt Dray

Tom Jemmett

5 September 2024

The New Hospital Programme (NHP)

• A manifesto commitment
• Future activity must be modelled
• Need consistency across schemes

• 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.

::::

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

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} , SQL
• Model: Python , Docker
• Apps: {shiny} and {golem} , Posit Connect
• Infrastructure and storage: Azure
• Documentation: Quarto
• Version control and collaboration: Git , GitHub

• 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.

• 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.

• 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

• 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

• Using R and Python to Model Future Hospital Activity: The New Hospital Programme Demand and Capacity Model
• YiWen Hon, Matt Dray and Tom Jemmett
• The Strategy Unit, NHS ML

• 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.