Smarter than the average service?
As Professor Terry Young writes, overcoming the obstacles facing ICS development will require a major rethink in how care is delivered.
As Luna Rossa eased into the America’s Cup final, I read that Italy’s 60 million people included 59 million sailing experts, such was the intoxication of tons of boat rising from the water to outpace the wind on foils the size of coffee tables.
Many long to see the NHS break free in a similar way. Just as the mariners had to get their heads around sails that are really wings and boats with dry hulls, so we must grasp counterintuitive thinking to get ICSs out of the water. Specifically:
When I was in R&D, we would guess production costs using a scaling rule: each time production doubled the unit price would fall by 20 per cent. We started with our lab prototypes and applied the rule from there. Later, I found scaling rules everywhere. Even cities get 15 per cent more productive when they double in size (Geoffrey West’s TED Talk).
Scaling rules drive and are driven by volume: cost and quality improve with volume. Single systems serving larger communities, should reap the benefits. However, scaling rules create profound pressures in any system and may eventually force the NHS to choose between going with the grain or forging on against it toward high quality and lower costs regardless of prevalence. An example of such choices concern standardising, since scaling works best where the volumes are largest: if you offer two angiogram procedures, for instance, you lose the productivity boost, even if you boost activity.
However, in the commercial world, there are ways high-volume markets feed niche applications (which may become high-volume). I was born the month Theodore Maiman lit his first ruby and have followed lasers from glass tubes to printed chips. Prices fell steadily and dramatically for decades and suddenly everyone needed a laser. However, no-one can laser-level a construction site until someone else makes lasers cheap enough for civil engineering. Most of today’s high-volume laser applications were unforeseeable in 1960.
Health caught this wave as off-patent drugs were tried on different diseases. Successful ICSs may even see the wholesale plunder of what works for common illnesses to harvest the benefits of scale for rarer conditions. Like sailing with a wing, you need to think differently.
Emergency Departments (ED) have been a global challenge for decades. This is because systems naturally restore their equilibrium, and EDs are part of something bigger. Whatever you do in the ED, the wider system restores the status quo (and usually the queues).
While this behaviour looks like a form of resilience, it can mask the impact of change until the system reaches the edge of viability. At that point, even a minor event can trigger collapse.
ICSs will therefore need new ways to measure underlying performance, as well as regular stress testing to assess how close each part of the system is operating to a game-changing boundary.
For these and other reasons planning is a new challenge for ICSs.
When I taught project management, I discovered that software engineering had pioneered a path for health. In the ‘50s, the software needed was relatively obvious, so the waterfall model emerged where requirements were collected. Designs flow from there and were built into something that could be tested. Once released, software required only maintenance.
By the ‘80s it was impossible pin down all requirements or write a good product in one pass, so flexibility was needed. As an example, the spiral model follows the waterfall model in moving logically from requirements through implementation to testing but continues to do so using prototypes until the latest trial meets the need.
Today, methods such as agile cope with the extremes of modern systems. Agile shrunk the documentation, much as foil racers shrank their keels. Agile meets needs quickly and moves on. It’s not the whole story of systems design, but it’s a start.
The raft of ‘how to’ guidance on ICSs shows that we are still in waterfall land. However, nobody can lay down a set of requirements that could lead inexorably to a fully deployed ICS. As software engineers discovered, we will need greater flexibility in design.
It would also help us if we grasped how differently a successful ICS could look compared to anything we know today.
ICSs are a wonderful prospect but require a change in mindset something like that needed to fly a boat. Unlike flying pigs, however, flying foils may appear any time on a screen near you.