Data and clinical backlog management

Weeknotes 1.8

The last week has posed interesting questions about productivity and what this means in the context of digital health technologies. 

It’s clear that although we have more mature clinical systems and data sharing technologies than at any time in the history of the NHS, staff, patients and commissioners do not consistently feel the benefits. This challenge is seen in many other industries and often know as Solow’s (or the productivity) paradox. Although national data prove that there are millions more GP appointments delivered nationally each month and more consultants working in hospitals, staff still feel like they are struggling and patients are waiting longer than they should. Looking this week at the genuinely incredible information tools being built in Greater Manchester it feels more important than ever to ensure that we focus on how these are designed and delivered to ensure that they help our staff deliver patient care, and do not add to what may be an unmanageable burden of work. 

One of the fundamental promises of digitisation in healthcare is the ability to create and share important data. In theory (and in practice) this should help clinical teams come to better, safer, faster judgements and improve the patient experience by reducing the number of times they are asked the same question. One unintended (though not unforeseeable) consequence of broader access to data is the opportunity to always do more. When information can be freely shared so too can the responsibility and desire to take action against what this is telling us. However, adding more activity into parts of our system that are not designed to deliver it will create inefficiency. And delivering more activity that is not value add in terms of patient experiences or outcomes will create work without driving benefit. Busy work is not valuable work in any setting. 

This challenge is well understood in Agile software development. Here ideas are cheap but execution is expensive due to the dependancy on skilled engineers to write code and build products. When the volume of additional feature / development requests exceeds the ability of software engineers to deliver on these (an input : output imbalance), a backlog develops and time to delivery increases. Having a small, meaningful, manageable backlog is probably a good thing (to prevent inefficiency from underutilisation of skilled staff). However, when the backlog grows unchecked it becomes wasteful. Wasteful as there is time spent developing ideas that can’t be delivered; wasteful as changes to the product before delivery of the backlog may change the nature of the problem; and wasteful because money and time is spent managing this.

Fab image from Lucas F Costa

The aim is to find the point of equilibrium between requests/inputs and develop features/outputs. This is why investing effort in meaningful prioritisation decisions is a key activity. 

I’m not certain that we have a model of how to do this in healthcare. Orthopaedic surgeons are highly trained and expert in their field. We could give them more information on blood pressures and ask for this to be addressed as pat of a surgical pathway… but do we want surgeons to spend time on this at the expense of operating? Where are they most productive? We need to intentionally use data not only to understand what healthcare improvements can be made but also to understand where and how to best to make these changes. 

From my ivory tower of renal medicine, I suspect this challenge is most acute in general practice. Here we have expert generalists (and more!) who have a clearly defined role, but risk being the catchall for work that needs to be done, but that is not being delivered elsewhere. This represents a system design challenge. Process and responsibilities in the NHS are historic. The ways in which we plan for, deliver and coordinate work in different parts of the system emerge as artefacts of the technical (and social conditions) of their time. Failing to curate and evolve these for our more digital and data rich age creates process debt where we create change within systems rather than changing our approach from the ground up. This approach is tempting given our desire for quick wins. However, established systems are resilient to change whereas tasks or processes within them are more readily influenced. This drives us to look at improving single parts of a system rather than redesigning the whole. This will normally shift rather than solve the constraint – we move the problem rather than solving it.

In Greater Manchester we have the potential to take a different approach and to do things better. It won’t be easy. It will need new approaches. It will need honest conversations about what staff can & cannot and should & should not be asked to deliver. We will all need to reconsider how we deliver care – not in relation tour individual services, but in the context of delivering better care within an integrated system. We need to use our data to inform this without expanding clinical care backlogs. I’d be delighted to speak to anyone with ideas! [email protected]


Posted

in

by

Tags:

Comments

One response to “Data and clinical backlog management”

  1.  Avatar
    Anonymous

    > Although national data prove that there are millions more GP appointments delivered nationally each month and more consultants working in hospitals, staff still feel like they are struggling and patients are waiting longer than they should.

    I don’t think this gets your point across at all. The linked data on “more GP appointments” is actually on closer inspection more primary care appointments. Which are not the same thing. There are actually less GPs[1] – which would go some way to explain why patients are waiting longer to see one despite the political spin that there are millions of more appointments.

    That this data on primary care appointments is so misleading is rather illustrative in and of its self.

    [1]:https://www.pulsetoday.co.uk/views/dr-burnt-out/not-enough-gps-thousands-of-us-are-now-unemployed/

Leave a Reply

Your email address will not be published. Required fields are marked *