Improving Improvement

The Engineering Better Care report was developed by the Royal Academy of Engineering in collaboration with the Royal College of Physicians and the Academy of Medical Sciences as a framework, based on a series of questions related to people, systems, design, risk and management perspectives on a systems approach to design and continuous improvement.

Use of the approach is increasing with an ongoing collaboration with the Royal Academy of Engineering, the Royal College of Physicians, the Royal College of Anesthetists, the Academy of Medical Sciences, the Health Foundation and the University of Cambridge Engineering Design Centre. This Toolkit is the first prototype derived directly from the original report and is currently undergoing evaluation and improvement within the improvement community. This Toolkit makes a number of changes to the original systems approach presented in the Engineering Better Care report, which have resulted from extending the original work and applying it to a number of practical examples. These changes do not impact the consensus achieved in drafting the original report, rather ensure it remains coherent in its expanded and more practical form.

The Engineering Better Care report has the sub-title a systems approach to health and care design and continuous improvement, and the approach described in this toolkit is intended to accommodate both design, where there is a desire to develop something new, and continuous improvement, where there is a desire to improve an existing system. In practice, it is rare that a completely new system is designed, rather such a system is typically derived from a mix of pre-existing, improved and new elements, where a combination of improvement and design is then required. In particular, this toolkit focuses on the early stages of design and improvement where decisions are made regarding the scope, aims and key themes for the improvement process.

This section will introduce and describe the thinking that underpins the spiral model of improvement described in Engineering Better Care report. This model is then extended and integrated with a hexagon model of the improvement process.

A system (or system of systems) is a set of elements: people, processes, information, organisations and services, as well as software, hardware and other systems that, when combined, have qualities that are not present in any of the elements themselves.

A system is delineated by its spatial and temporal boundaries, surrounded and influenced by its environment, described by its structure and purpose, and expressed in its functioning. In other words, the whole is very likely to be greater than the sum of the parts. For example, the human body is a system of systems where each has its own purpose and function. When combined, the systems produce for the body qualities not present in any of the individual elements. Conversely, if any individual system is compromised or a part of the body is damaged, the overall function may be significantly or terminally impaired.

The engineered world is full of systems. From the simple water heater to the fully integrated international airport, from ancient irrigation systems to modern communication networks, all systems share one key feature: their elements together produce results not obtainable by the same elements alone. These elements, or parts, can include people, processes, information, organisations and services, as well as software, hardware and other systems.

A systems approach uses a range of techniques to determine requirements for the system, organise its structure, create and evaluate alternative designs, produce quantitative analyses and predictions where appropriate, assess possible threats to and opportunities for people and other systems, integrate all the individual elements and deliver a system that is shown to be fit for its intended purpose. A true systems approach does not deliver solely technical solutions; rather it ensures the appropriate alignment of technology, processes, interactions and policy to deliver innovative responses to today’s most complex and pressing challenges.

The layout of the system, defining all the elements and their interconnections, needs to be carefully considered to ensure that each element on its own and in combination with others performs as required. In response to this challenge and the ever increasing complexity of modern systems, a new discipline of systems engineering has evolved as an interdisciplinary approach to enable the realisation of successful systems.

Engineers routinely use a systems approach to address challenging problems in complex projects. This allows them to work through the implications of each change or decision they make for the project as a whole. They consider the layout of the system, defining all the elements and interconnections, to ensure that the whole system performs as required. One example is the successful delivery of the London 2012 Olympic and Paralympic Games. Physical infrastructure and practical organisation were brought together, with innovative physical engineering, modelling and simulation of people flows, early testing of venues, and extensive risk management. A systems approach, combined with tried and tested engineering methods and tools, delivered real success on a massive scale.

Systems engineering focuses on defining stakeholder needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem. It integrates all the necessary disciplines and specialty groups into a team responsible for using a structured development process that proceeds from needs to requirements to concepts, and from design to production to operation, addressing all the stakeholders’ business and technical needs.

A successful system delivery process brings together technical specialists and system architects to ensure a holistic system perspective is maintained throughout; not only in terms of the overall layout of the system and its elements, but also with regard to the whole system lifecycle. Some will provide a focus on individual elements and their role in the system, others will take a holistic view of the system and its performance. Both will play a part in defining the boundary of the system, its requirements, the partitioning of its elements and interfaces, its integration and evaluation, and ultimately its release into service. Typically, different and yet coherent perspectives of the system are developed and held by different teams and stakeholders.

A systems approach uses a range of techniques to determine requirements for the system, organise its structure, create and evaluate alternative designs, produce quantitative analyses and predictions where appropriate, assess possible threats to and opportunities for people and other systems, integrate all the individual elements and deliver a system that is shown to be fit for its intended purpose. A systems approach, built on these perspectives of people, systems, design and risk, can be applied to the design and improvement of systems across many areas of health and care.

Ultimately, a systems approach aims to determine the system design and implementation that delivers the best service. It has the potential to drive greater efficiency and a better understanding of threats and opportunities present when shaping the delivery of health and care services, and brings together the four key and complementary perspectives of:

• People: understanding of interactions among people, at the personal, group and organisational levels, and other elements of a system in order to improve overall system performance (identify, locate, situate)
• Systems: addressing complex and uncertain real world problems, involving highly interconnected technical and social elements that typically produce emergent properties and behaviour (understand, organise, integrate)
• Design: focusing on improvement by identifying the right problem to solve, creating a range of possible solutions and refining the best of these to deliver appropriate outcomes (explore, create, evaluate)
• Risk: managing risk, based on the timely identification of threats and opportunities in the system, assessment of their associated risks and management of necessary change (examine, assess, improve).

All these perspectives are inextricably linked and uniquely contribute to a systems approach. It is only when all four are robustly understood that a systems approach will have the greatest success. Their scope, purpose and operation can be summarised through the answers to a number of high-level questions that were developed and agreed during the project workshops that preceded the Engineering Better Care report.

A systems approach can be applied to the design and improvement of systems at all extremes of scale, with service level improvement taking place within a wider context that may subsequently require changes at the organisation level and cross-organisational level. Within the delivery of health and care, many systems are distinct and can be operated independently, yet are also connected to or integrated with other systems, either in layers or as part of a network. The strength of a systems approach is its ability to overcome the complexity associated with such systems of systems and deliver solutions at all levels of scale regardless of the form of the system. Its value has been recognised in health and care and increasingly referred to in national policies and used in improvement methods.

Adopting one or more of the perspectives on current practice can be done by simply asking the appropriate people, systems, design and risk guiding questions.

People

Identify: Who will use the system? — leads to an understanding of the diversity of people involved and their needs and capabilities.

Locate: Where is the system? — leads to an understanding of the physical, organisational and cultural context of the system.

Situate: What affects the system? — leads to an understanding of the political and policy landscape within which the system is situated.

Systems

Understand: Who are the stakeholders? — leads to a common view of the stakeholders and their individual interests, needs, values and perspectives.

Organise: What are the elements? — leads to an agreed system boundary, architecture and details of the interfaces between all the system elements.

Integrate: How does the system perform? — leads to an integrated, operational system that is proven to meet the stakeholder requirements.

Design

Explore: What are the needs? — leads to a common understanding of the needs for a system, taking account of the full range of stakeholders.

Create: How can the needs be met? — leads to a range of possible solutions that would help meet the needs identified by the explore phase.

Evaluate: How well are the needs met? — leads to an evaluation of possible concepts that could meet the needs identified by the explore phase.

Risk

Examine: What is going on? — leads to an understanding of the system architecture and details of the interfaces between the elements.

Assess: What could go wrong? — leads to a systematic assessment of the likelihood and potential impact of threats to the system.

Seek: What do we do well? — leads to a systematic assessment of the presence and potential impact of opportunities within the system.

Improve: How can we make it better? — leads to a range of possible solutions that would help mitigate the threats or exploit the opportunities.

Note, this toolkit expands the original Assess question from Engineering Better Care report into two complementary approaches for reducing risk. The What could go wrong? question attempts to reduce risk by minimising things going wrong. The new Seek question, What do we do well?, reflects an alternative approach to reduce risk by maximising the things that are done right.

There should also be an emphasis on integrating people, systems, design and risk thinking within the context of the project management of the improvement process. Further questions are introduced later that address the broader challenges of such a process.

Management

Trigger: Why are we doing this? — leads to a documented rationale for improving an existing system or developing a new one.

Problem: What is the problem? — leads to a clearly articulated view of a better system based on an understanding of the current system.

Team: Who should be involved? — leads to a common and clearly articulated understanding of who should deliver the improved system.

Success: What does ‘good’ look like? — leads to a common and clearly articulated understanding of success and how it would be measured.

Plan: What should we do next? — leads to the ongoing development and execution of a plan of action to deliver the system in a timely manner.

A review of the people, systems, design, risk and management questions reveals a degree of overlap between them. This should be of no surprise, particularly due to the related nature of the systems, design and risk perspectives. Where an individual perspective is to be used for improvement, all the questions within that perspective have a purpose and enable a standalone introduction to that perspective. However, if an integrated view of the perspectives, or a systems approach, is required it is appropriate to remove any overlap or redundancy.

In a pragmatic attempt to rationalise the questions, there are a number of observations that can be made:

1. The What is going on? question from the risk perspective delivers a picture, or map, of the system and may be assumed to be incorporated within the What are the elements? question from the systems perspective.
2. The How can we make it better? question from the risk perspective delivers set or requirements for improvement and may be assumed to be incorporated within the How can the needs be met? question from the design perspective.
3. The Why are we doing this? question from the process perspective is a one-off question designed to capture the original rational for the improvement and is unlikely to be repeated. It does not appear in the following model, but is important later when discussing the broader improvement process.
4. The What should we do next? question from the process perspective is a recurrent question that should always be asked and not constrained to any particular point within the process. It also does not appear in the following model, but is integral to later discussions on the broader improvement process.
5. The questions form a natural cycle, beginning with those that are more about understanding the context and definition of the problem, and ending with those relating to the delivery and evidencing of a solution.
6. The questions within each perspective are iterative, as are those when combined to form an integrated systems approach.

In summary, the systems approach described in Section 5 of the Engineering Better Care report includes a spiral diagram with 13 questions, which are a sub-set of all the questions from the different perspectives. The equivalent spiral diagram presented in this section includes the additional What do we do well? question, and thus contains 14 questions.

The spiral model shows a natural order for the steps. It also highlights that a systems approach is not a simple linear process, but an iterative process of continuous improvement. It suggests that the first question to be asked concerns the problem to be addressed by the system. This would be followed by questions based on people to understand the background and context to the new system. The questions on systems, design and risk are then interwoven with the management questions to provide an opportunity to specify, design and evaluate the system and its constituent elements, with a question on what a good outcome would look like early in this sequence.

The idea would be that in the first pass of the questions, preliminary answers would be provided. Further passes would offer an opportunity to provide more detailed answers or again to skip and use the previous answer for that iteration. This process affords the opportunity to progressively increase knowledge of the problem, reduce uncertainty regarding the solution, and manage the implementation risk to an acceptable level. Ultimately, the answers would form a description of the improved system.

It is expected that the methods used to answer the questions would increase in complexity as each question is revisited, until further effort brings limited benefit to other questions in the cycle. For example, initial answers might be based on estimates or knowledge of previous solutions, while later answers could be determined by extensive investigation, advanced modelling and simulation, or evaluation of prototypes.

The spiral model provides a useful, but rather abstract view of improvement. It would be more helpful to elaborate this simple model, in the context of challenges of a broader systems improvement process, using a stage based approach that can be used to progressively increase the clarity of definition of the revised system while reducing the operational risk. Each of the improvement stages can then be inspired by the adoption and appropriate adaptation of the individual people, systems, design, risk and management perspectives.

This approach is common to all improvement processes where the focus on moving a system from its current performance to a future, measurably better state. Such processes typically include a number of key stages to ensure success:

• Understand — leading to a description of the current system (now), a common understanding of the problem, a consensus view of what the future system might look like (better) and a clearly articulated case for changing the system.
• Co-design — leading to a clear description of the future system, based on the iterative design of the system architecture with its elements and interfaces, the evaluation through successive prototyping of its likely behaviour, and a plan for its delivery.
• Deliver — leading to the successful deployment of the new system with the levels of measurement necessary to evidence its success, and acceptance that it achieves appropriate value for its stakeholders.
• Sustain — leading to the continued operational success of the new system along with consideration of further improvement potential or wider deployment.

In this model of the improvement process, the case, plan and acceptance refer to the delivery of improvement, rather than to any performance targets for particular stages of this process. The accommodation of interim targets for each stage of the improvement process is described later.

The spiral model allows the questions to be overlaid on the existing improvement process, at sufficient intervals and to the level of precision required, while ensuring that they are asked in an appropriate order. The spiral model is also adaptable to all levels of scale, from the service level, through the organisation level to the cross-organisational level, and is sufficiently versatile to apply across all areas of health and care.

The early iterations of the spiral would focus on increasing understanding of the problem and, if a case for change is agreed, later iterations would provide more focus on the design and delivery of the system and its sustainability. The model also lends itself to the development of systems of systems, where early iterations of the spiral would focus on architecting the overall system, leading to parallel iterations to develop and deliver individual systems, and further iterations to ensure their integration and subsequent evaluation of the overall system.

The ultimate success of the systems approach would depend on keeping all of the relevant questions in mind on each iteration. In practice, a degree of concurrency across the stages is required. The Understand stage requires adequate consideration of the Co-design, Delivery and Sustain stages to create a clear view of the future system, while the sustain stage depends on consideration of sustainability issues throughout the previous stages. Such concurrency, or involvement of key stakeholders throughout the improvement process, is essential if new performance targets are to be realised in a safe, timely and cost-effective manner.

The stages of the improvement process may also be considered as a collection of activities, executed in some form of order to ensure the efficient and effective running of the process based on the desired outcome and the availability of resources. Each of the stages will have a specific beginning and corresponding goal to enable the delivery of an improved system.

The overall process may range from the improvement of a well defined local system to the design of a new extended system of systems. In all cases there is a need to understand the current performance (or absence of performance for a new system), define a target for what is measurably better and capture the trigger for the improvement. The process may also be divided into a number of stages: to focus delivery on interim outcomes; to review and accept such outcomes; and to authorise continuation of the improvement programme.

All improvement processes are initiated, and potentially shaped, by their trigger, which may be classed as:

• Strategic — where risk reduction and improvement is part of an ongoing strategic initiative.
• Incident — where an event has resulted in actual or potential harm to patients or clinicians.
• Local — where the potential for incidents has been identified locally.
• Routine — where a team or individual wishes to check the integrity of their service.
• Improvement — where changes are planned to an existing service or system.
• New — where a new service is to be introduced into practice or an existing one decommissioned.
• Technology — where new equipment or technology is to be introduced to an existing service.
• Estates — where estates or buildings are being built, refurbished or maintained.
• Staff — where new staff are to be introduced to an existing service or exiting staff levels are changed.
• External — where specific strategic changes or checks are externally requested.
• National — where teams are encouraged to propose and deliver national service improvements.

A clear understanding of the trigger helps to identify the initial scope of the improvement and ensures that an appropriate team is assembled to initiate any subsequent improvement process. Whether the trigger relates to people, systems, design or risk, a systems approach will consider all of these perspectives in a seamless and integrated way.

The improvement process may be extended to include reference to the case required for change and programme or plan for change, both of which need updating through the different stages of the programme. For example, the strategic case might include only the case for undertaking the preliminary investigation and design while the full case would be that for the subsequent delivery of a better system.

The extended improvement process raises a number of additional management questions, including the previous Trigger and Plan questions:

Trigger: Why are we doing this? — leads to a documented rationale for improving an existing system or developing a new one.

Current: What do we do now? — leads to a detailed description of the current system architecture and its observable behaviour.

Performance: How do we perform now? — leads to the qualitative and quantitative evaluation of the performance of the current system.

Better: How could we improve? — leads to a preliminary description of a better system architecture and its intended behaviour.

Measure: What should we measure? — leads to the identification of possible performance indicators for the improved system.

Case: What is the case for change? — leads to the definition of a case for change from the current system to one that is measurably better.

Plan: What should we do next? — leads to the ongoing development and execution of a plan of action to deliver the system in a timely manner.

In addition, there is the a question relating to the strategic purpose of the current system or the system to be designed, as distinct from the purpose of the improvement process:

Purpose: What is the purpose? — leads to a detailed description of the purpose of the current system within its wider context.

The spiral model of 14 questions (presented earlier in this section) is now reviewed in combination with the additional management questions that relate to the wider improvement process. Once again, it is no surprise that some of these questions overlap. A number of the additional management questions are similar to the systems and design questions and relate to descriptions of the improvement process at different levels of detail. Where the improvement process perspective is to be used on its own, the questions enable a standalone introduction to improvement. However, if an integrated view of the perspectives is required in order to deliver a complete improvement process, it is more appropriate to remove any overlap or redundancy.

In a pragmatic attempt to rationalise the questions, there are a number of observations that can be made:

1. The What do we do now? question from the improvement perspective delivers a picture of the system and may be assumed to be incorporated within the What are the elements? question from the systems perspective.
2. The How could we improve? question from the improvement perspective delivers a set of requirements for improvement and may be assumed to be incorporated within the What are the needs? question from the design perspective.
3. The questions can be set in an order most likely to deliver a successful improvement programme, with those focused on understanding the problem preceding those focused on delivering a robust solution to the problem.
4. The questions within each perspective are iterative, as are those when combined to form an integrated systems approach.
5. There is likely to be the need for an initial ‘Initiate Stage’ to facilitate the building of an improvement team and the scoping of the improvement process.

In summary, the spiral presented in this section included 14 questions. A simplified cyclical form of this spiral (presented opposite) now contains 21 questions, resulting from the addition of further questions related to the wider improvement process, and the removal of overlapping questions.

The cyclical model reinforces the view that a systems approach is not a simple linear process, but an iterative process of continuous improvement. It suggests that the first question to be asked concerns the purpose to be addressed by the system. This would be followed by questions based on the perceived problem and about people to understand the background and context to the new system. The questions on systems, design and risk are then interwoven with the management questions to provide an opportunity to specify, design and evaluate the system and its constituent elements, with a question on what a good outcome would look like early in this sequence.

As with the spiral model, the idea would be that in the first pass of the cyclical model, preliminary answers would be provided to the questions. Further passes would offer an opportunity to provide more detailed answers or again to skip and use the previous answer for that iteration, with repeated reference to the question at the centre of the model. This process affords the opportunity to progressively increase knowledge of the problem, reduce uncertainty regarding the solution, and manage the implementation risk to an acceptable level. Ultimately, the answers would form a description of the improved system.

As with the earlier model, it is again expected that the methods used to answer the questions would increase in complexity as each question is revisited, until further effort brings limited benefit to other questions in the cycle. For example, initial answers might be based on estimates or knowledge of previous solutions, while later answers could be determined by extensive investigation, advanced modelling and simulation, or evaluation of prototypes.

The world is made up of a set of highly interconnected technical and social elements that produce emergent behaviours and challenges for communication and control. Some systems are simple, others are chaotic. Some are complicated with many elements, but operate in patterned or predictable ways, others are complex with features whose interactions are continually changing and whose behaviour may only be understood in retrospect.

In health and care it is the co-production of health outcomes with the patient, often across a number of systems rather than with any individual health and care system, that can add significant complexity and uncertainty, leading to behaviours not expected when focus is limited to individual systems. Although the majority of individual health and care systems are simple or complicated, the combined behaviour of such systems working together is more likely to be complex or, in extreme cases, chaotic. This is particularly true when there is significant uncertainty or variation associated with the patient population accessing the system, both with regard to their medical conditions and the timing and choices they may exercise over their care.

The sequence of questions in the cyclic model not only provide an excellent starting point for delivering a successful improvement process, but also address a number of other topics that should be considered when designing complex systems:

• Behaviour — when integrating people, processes, technology and the built environment, it is hard to predict all the behaviours that will subsequently emerge. It is important to design for intended behaviours and outcomes, observe the resultant system behaviours, identify unintended consequences and predict possible variations over time (questions: problem, identify, locate, organise, evaluate, assess, integrate).
• Measurement — systems behave in a variety of predictable and less predictable ways in response to internal and external data and events. It is important to understand the need for measurement of a system’s performance, implement the means to facilitate such measurement and determine the way in which the resulting data will be used (questions: success, organise, explore, create, evaluate, integrate).
• Communication — dysfunctional teams are unlikely to deliver good systems; functional teams are more likely to do so. It is important that the team talks to one another, develops clear plans and instructions, ensures there is a common understanding of the system and engages with all the stakeholders, particularly the users, in the delivery of the system (questions: identify, locate, understand, organise, integrate, plan, team).
• Learning — the ability of individuals and organisations to learn enhances their chances of delivering and sustaining effective systems. It is important to develop a culture of continued learning for all stakeholders, build capacity within organisations to deliver effective systems and share stories of success to inspire future systems-based change (questions: identify, locate, situate, team).
• Interfaces — systems are only as good as their interfaces. Between every element of a system there are interfaces to other elements or systems. It is important to organise the elements of a system, define and maintain the necessary interfaces between them, and define and manage the interfaces between the system and its environment (questions: problem, identify, locate, organise, success, integrate).

A further issue that impacts, and is impacted by, all of the above topics is emergence, i.e. the principle that systems exhibit properties which are meaningful only when attributed to the whole, not to its elements or component parts. Such behaviour is a consequence of the relationships between the elements, rather than the behaviour of individual elements, and is typically observed at the highest level of the system. Emergence is affected by the structural complexity of the system, the complexity of individual elements and the level of uncertainty present within the system.

The improvement questions can be applied to simple systems as well as more complex systems of systems. As the complexity of a system increases it is important to consider the design of the architecture of the system as a whole as well as the detailed design of the corresponding elements or sub-systems. The people, systems, design, risk and management questions may then apply at all levels of abstraction of the system.

The architecture of the system may be influenced by a number of factors, including: local, regional or national organisational boundaries; geographical boundaries; technical disciplines; disease types; the themes of the higher-level, parent system; of some combination of the above. Systems may have any number of levels of hierarchy, but whatever the rationale for the system architecture, the answers to the people, systems, design, risk and management questions for each sub-system should be consistent with those for the parent system and other adjacent or lower-level sub-systems.

The improved system may comprise a mix of pre-existing, improved and new elements, where a combination of improvement and design is then required. The improvement team may also comprise a number of sub-teams, focused on different levels or elements of the system, where careful coordination of the teams will be necessary.

The trigger for improvement may also come from a variety of sources. As a result there are numerous entry points for the cycle of questions, each one of which may result in a different initial sequence of questions. There is no absolute necessity to ask all the questions on each circuit of the cycle, rather it is appropriate to ask those that will give most value to the improvement team in gaining a rich picture of the particular needs for any subsequent improvement process.

A routine (A), internal service-led trigger may result in initial ideas and a rudimentary risk assessment before the full cycle of questions is undertaken. Conversely, an external (B), national, policy-led trigger may result in a swift cycle of questions up to the point that a design need is recognised before the full cycle is started. There is no right or wrong sequence of questions, more a pragmatic view of those that need to be answered and the means to do so. In practice, a number of questions may also be answered in a single meeting, while others may required a series of meetings to provide a single answer.

Clarkson PJ, Bogle D, Dean J, Tooley M, Trewby J, Vaughan L, Adams E, Dudgeon P, Platt N, Shelton P (2017). Engineering better care: a systems approach to health and care design and continuous improvement. Royal Academy of Engineering, London, ISBN: 978-1-909327-35-1.

Davidoff F, Dixon-Woods M, Leviton L and Michie S (2015). Demystifying theory and its use in improvement. BMJ Quality and Safety, bmjqs-2014-003627.

Dixon-Woods M & Martin G (2016) Does quality improvement improve quality? Future Hospital Journal, 3(3):191-194.

Fillingham D, Jones B, Pereira P (2016), The challenge and potential of whole system flow. The Health Foundation, London UK.

Ham C, Berwick D and Dixon J (2016). Improving quality in the English NHS: a strategy for action. King’s Fund, London, UK.

Langley GL, Moen R, Nolan KM, Nolan TW, Norman CL, Provost LP (2009). The Improvement Guide: A Practical Approach to Enhancing Organizational Performance (2nd edition). San Francisco: Jossey-Bass Publishers.

McGuire KJ and Spear SJ (2015). Beyond the Jargon: architecture, process and clinical care, SPINE, 40(16):1243-1246.

Snowden DJ, Boone ME (2007). A Leader’s Framework for Decision Making. Harvard Business Review, BR0711.

The Health Foundation (2013). Quality improvement made simple: what everyone should know about health care quality improvement. The Health Foundation, London, UK.