We associate flywheels with Birmingham’s great engineer Matthew Boulton who teamed up with James Watt 250 years ago to start the industrial revolution. Magically, its momentum keeps things going while the cylinders prepare for their next kick.
A spinning flywheel needs very little energy to keep going, hence the many flywheel models of good business practice, including a famous example that Jeff Bezos drew on a table napkin. Here’s a simple flywheel that explains how on-line retailers, for instance, are changing the world.
When you order your Friday night take away there is clearly smart work in a kitchen somewhere, in an office somewhere, and on the roads, to cook and then deliver your choice of meal to the door while it is still hot.
We relate to the activity but are less aware of the information processing that makes it a success. For each menu item and delivery, the cooking, packing and travel cycles are logged. The time it takes to ‘phone an order through or the number of clicks needed to assemble it on-line are also tracked and analysed, so that every month the service gets a little better. The better your experience, the more you buy!
The information-process flywheel is driving most consumer activity, and the NHS plans to harness it for better care. Key to healthcare success is the idea of alignment: that the information collected or available is appropriate for good service provision, and that services in turn yield the best information to drive the flywheel on.
Health data: hidden information, visible improvement
In late March 2020, an emergency drive through near the NEC Nightingale Hospital was rapidly deployed by Birmingham and Solihull CCG. Following this, Badger (Birmingham and District GP Emergency Room) Group took on the flow and capacity modelling and into 2021 it went on to design and deploy several rapid access care facilities. This process culminated in a drive through out of hours GP service. The ‘process’ side of this flywheel has been well documented (see here or here), so now we turn to the information system.
Figure 2 came out of the analysis to identify who needs to know what when, and who needs to communicate what from where.
The sources of information may be the patient’s home, since the patient may call 111, their GP, or make a direct booking to a rapid access facility. However, the patient may already be at the GP’s or even in A&E, so onward information flows must also be supported. Similarly, the staff at 111 may want to forward information they have received (especially if the patient is coming in), while the GP will need to be informed of the patient’s needs and plans, whether the patient is at the practice or not.
Each of these groups – the rapid access facility, the GP, the local A&E and NHS 111 – has its own information system, so the communication ideally has to be through interfaces that communicate bilaterally which each partner in the process. Of course, all signalling must be secure and when you add in the need for real-time referrals and bookings, the difficulties of providing alignment between the logistics of running the centre and the supporting infrastructure become clear.
Badger Group has a health care systems engineer on the team and access to a digital systems and software engineer. As noted above, health care systems depend heavily on information flows, so a health care system engineer needs to be a digital systems engineer as well as a process engineer as well as possessing a wealth of health care domain experience. While software engineering may be contracted out, it helps if a health care systems engineer can develop code.
Badger uses Adastra as its clinical record system and the system used by NHS 111, for instance, can make electronic referrals to Adastra. However, the drive through on-line booking system is not directly connected to Adastra and is accessed through a browser.
A prototype for the booking system shown in figure 3 was rapidly developed for the NEC centre and was further evolved to provide the critical information flows to support rapid access care. It is a fairly standard solution for this type of scenario. The information system was a mix of code for interfaces and installed software, with the most significant pieces of development being the graphical user interface (GUI) and the database.
In the figure 3, the user on the left could be:
- A GP referring a patient
- Badger staff on the ground checking the patient in
- Badger staff at base managing the live worklist and transferring the referrals to the Adastra EPR system (copy-and-paste)
- Badger managers who set the number of slots and monitor the high-level flow reports.
- Later, patients themselves who could self-book online without needing to go through a GP
Spinning up the flywheel
Alignment often proves elusive where software is procured from one agency, service design from another, and service delivery from yet another. However, because the critical software was developed concurrently with, and by the same team as designed and delivered the logistics and patient flows, excellent alignment was readily achieved.
It has therefore proved amazingly flexible. It supports patient-led bookings into closely coordinated slots for waiting-free appointments. It supports referrals from GPs and A&E departments to the rapid access facilities as well as onward referrals from the rapid access facilities, as needed.
Can a version of the already successful business flywheel be made to work in healthcare service delivery?
Of course! It’s here already.