Transforming Hospital Planning with an Open-Source Demand Model

Chris Beeley

4 September 2025

Prologue

  • There is much to say

Gif of a cat saying 'I can talk. I have so much to say'

Intro

  • Why did we build this model
  • What does it do
  • How was it created
  • What did we learn when we were building it
  • Who else might use the model in the future
  • (Sorry for the last two I saw a pattern and dug in)

Why?

  • New Hospital Programme came to the Strategy Unit c.2020
  • Predict demand for the future of the hospitals c.2041
  • We built on existing work and knowledge in the SU as well as the literature
  • I was not here!

The landscape

  • Lots of models
  • Lots of consultancy support
  • Lots of repetition / duplication
  • BUT no consistency about definitions
  • Methodological progress is slow
  • Proprietary models means progress is not shared

Common issues with models

  • Handling uncertainty
  • Unnecessary aggregation
  • Poor coverage of some changes
  • Systematic bias in model assumptions
  • Lack of ownership and auditability of assumptions

The principles

So what does it do?

'Gif of Homer Simpson pressing a button and saying 'do something cool'

The big picture

  • Demographic change
  • Non-demographic change
  • Categories of potentially mitigable activity
  • More to come

Demographic change

  • Population size
  • Population age profile
  • Age specific health status

Non-demographic change

  • Medical interventions
  • Clinical standards
  • Patient expectations

Categories of potentially mitigable activity

  • Admission avoidance
  • Length of stay reduction
  • Conversion to day procedure/ tele
  • Ninety two and counting (will have a look later)

The products

The model

  • Sample the parameters (assume normal)
  • Calculate demand at IP, OP, A&E level
  • Do this 256 times and plot the distribution
  • The results are conceptually at row level, but not in practice

The national elicitation exercise

Gif of Chuck Norris saying 'What do you think'

It’s a whole separate talk…

  • We asked experts to predict likely levels of mitigation in the future, in a structured way
  • We also made some whizzy data science tools to do it with- which ended up being really important and useful
  • It’s not my area so I won’t say any more- this was Prof Mohammed and team
  • We show these values to trusts to help them make better guesses about the future

Inputs

  • Let’s break a rule

Gif of a man saying 'I swear I never do this'

Outputs

  • We’ve come this far, let’s break the rule again
  • Note to self- if the vibe seems right kick off an “Analysis versus dashboards” bunfight

Now for the (data) science

Gif of a cat sitting on a keyboard with code on the screen

Big list of technical sounding words coming up…

  • SQL -> databricks
  • Azure compute (Docker)
  • Azure BLOB storage
  • Python for the model
  • R for reporting/ dashboards
  • Quarto for documentation

That’s what we did- how did we do it?

Gif of a cartoon character saying 'Guys, we need a plan'

Agile!

  • We are not doing “proper” scrum
  • Product owner, scrum master, everyone else
  • Five week sprints with a one week recovery run between each one
  • Sprint planning, sprint catchup, sprint retro

Sprint retro

  • What went well, what could have gone better, and what to improve next time
  • Looking at process, not blaming individuals
  • Requires maturity and trust to bring up issues, and to respond to them in a constructive way
  • Should agree at the end on one process improvement which goes in the next sprint
  • We’ve had some really, really good retros and I think it’s a really important process for a team

What did scrum give the team?

  • Simultaneous releases of linked repos
  • The team works autonomously in the sprint
  • Better conversations about “no”
  • The planning and retro process improves the team’s processes, not just the code

Product owner

  • My lessson- get out the way
  • A better connection between high level and low level planning
  • Clear release dates and responsibilities
  • Clear what I should be doing

Agility

  • This project was agile whether we liked it or not!
  • My 2022 agile definition:
    • Customers can’t make up their minds
    • It’s hard to design software all at once
    • Continuous delivery keeps customers happy

Agile manifesto highlights

  • “Welcome changing requirements, even late in development”
  • “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”
  • “Continuous attention to technical excellence and good design enhances agility”
  • “Simplicity- the art of maximizing the amount of work not done- is essential”

How scrum helped

  • Those shaping the project wanted to be able to make quick changes- and see the long term plan
  • Agility is a mindset, a mode of practice
  • If anything we were actually too agile
  • Being agile is all about being able to review and make decisions frequently
  • But it isn’t about changing what you’re doing all the time
  • Good code and good teams are ready to change direction- whether they change or not

Product!

Gif from the movie 'Taken' with the main character saying 'I don't know who you are, I don't know what you want'

What do we want?

  • Prioritised roadmap with appropriate stakeholder engagement!…
  • (Fairly) early days
  • We need to have structured and useful conversations with our users
  • We need to imagine other users for the products we already have and for the products we might make
  • We need to think of what we do not as a set of analytical tools or products but as a service, something that help people in the real world do their real job

The future

  • National and regional model runs
  • Bring your own data (FDP?)
  • Understanding more about categories of potentially mitigable activity, who thinks what’s possible, and why it matters
  • Increasing understanding of the shift from hospital to the community