Making improvements
This page provides guidance on how to go about making an improvement and solving your problem. Making an improvement involves identifying the causes to your problems in your current practice, generating ideas for improvements and performing Plan Do Study Act (PDSA) cycles using improvement science.
Improvement science refers to the methodology, tools and processes commonly used in health care to improve safety and quality structures, processes and outcomes.
If you are new to improvement science or would like to refresh your knowledge, visit the CEC Academy webpages to access a wide range of tools and resources to support your improvement journey.
You can also contact your Clinical Governance or Patient Safety Unit who can connect you with your local quality improvement (QI) experts. The CEC Academy or Medication Safety team can also be contacted directly with any questions you may have.
Remember the following steps of improvement methodology serve as a guide to conducting your own project. You are free to adapt the methodology to suit you and your team.
What is your improvement project aiming to achieve?
Once you have established the problem you want to solve, you need to develop an aim for what the improvement project will achieve.
The aim statement captures the goal of the project. The aim statement must address the problem and must not include any solutions.
The project's aim must be:
Tips:
- Remember, 'some' or 'better' is not a measure and 'soon' is not a time frame
- Start small and focus on an individual unit or ward (even if the problem may be more widespread). This will allow you to refine the new processes, demonstrate their impact on practices and outcomes, and build increased support with stakeholders. Then you can consider spreading the initiative to other parts of your service
- Avoid aim statements that suggest the desired solution to the problem, e.g. to implement the surgical antibiotic prophylaxis policy at your unit/ward.
Examples of aim statement include:
- Within 12 months, 95% of prescriptions for surgical antibiotic prophylaxis for General Surgery patients will be concordant with guidelines
- By December <insert year>, 95% of geriatric ward B patients labelled allergic to penicillin will have their allergy verified and validated
- Within 6 months, documentation of an indication for an antimicrobial will be 95% in general ward C
- Within 9 months, at least 95% of inpatients under the care of general paediatric teams prescribed IV antibiotic therapy are switched to oral therapy within 24 hours where safe and appropriate.
What is your current AMS practice?
It is important to review and understand your current practice to help identify problems or gaps.
Develop a flow chart of your current AMS practices with your team. Your flow chart is a diagram which should show each step and decision related to AMS practices, from the time a patient enters your ward/facility, until they are discharged.
The flow chart provides a helicopter view of how the current process happens, rather than what it should be, identifying all the points of decision-making and variation.
Remember to:
- Visualise the entire AMS process as it currently is
- Consider the current roles and responsibilities of each member of the team involved in the process
- Identify time critical points, gaps, variations in practice, bottlenecks and opportunities for improvement
- Identify areas where data may need to be collected to demonstrate the current reliability of the process (that is, how often the process occurs as planned in practice) e.g. specimens collected for microbiology before antimicrobials are commenced.
More information on flowcharts and how to construct one.
 | Flow Chart example |
There is also an example of a cause and effect diagram for surgical antibiotic prophylaxis.
Referring to your flowchart, you will have identified the potential gaps and issues with the current AMS process. The next step is brainstorming all the reasons as to why your problem exists – it is important that you are specific with your causes.
Find more information on brainstorming and the 5Ws and 1H method.
Brainstorming as a team will give you a better understanding of the problem you are aiming to solve. Without understanding all the causes of a problem, the solutions you generate may not actually lead to an improvement because they could be focused on the wrong part of the process, allowing the problem to continue.
This is an example of a Cause and Effect Diagram (also called a Fish bone Diagram or Ishikawa Diagram). It is an effective tool that allows people to easily see the causes contributing to a problem, as well as the relationship between the different causes.
How do you make sense of the problems identified?
As a team, it is an essential step in the improvement process to take note of all the problems you have identified and make meaningful sense of what you have found in order to plan for the next stage of the improvement project.
It is recommended as part of this process to involve your quality improvement advisor.
An affinity diagram involves sorting all the identified causes of the problem from the brainstorming process, into categories or themes. More information on how to create an affinity diagram.
| Affinity Diagram example |
A driver diagram is an extension of an affinity diagram. It is a visual tool that illustrates the relationship between the aim of the improvement project, the primary drivers (category headings) and the secondary drivers (causes of the problem).
Primary drivers are high-level factors that need to be influenced in order to achieve the aim. Secondary drivers are specific factors or interventions that are necessary to achieve the primary drivers.
Each secondary driver will contribute to at least one primary driver, shown via relationship arrows.
Information on how to create a driver diagram.
| Driver Diagram example |
What are change ideas or change concepts?
Solutions in quality improvement are commonly referred to as change ideas or change concepts. Change ideas are well defined change concepts or interventions to address the secondary drivers, that is, what exactly are you going to do and how will this be achieved?
As a team use the driver diagram to brainstorm solutions for each secondary driver. It is possible that a solution will address more than one secondary driver. It is important to note all improvement requires change, but not all changes lead to improvement.
It is not realistic or recommended to test several change ideas at once - if improvement occurs, how will you know which change idea or combination of change ideas led to the improvement?
Prioritising change ideas can assist with deciding which change ideas to test first.
For each change idea, consider:
- Will it be easy or hard to implement? (consider the cost involved, time involved, extent of training required)
- What impact will it have on achieving the aim?
- Consider the feasibility, time requirements, how the change will be done (that is, the logistics) and the expected outcomes of each change idea.
For example, removing 1 g vials of cefazolin from operating theatre imprest and replacing with 2 g vials is relatively easy to execute. The anticipated impact would be high – as it would make it easier for the clinician to administer the correct dose of 2 g cephazolin for most patients for prophylaxis (drawing up from one vial instead of two).
This change idea may be one that you might want to try early on in a surgical antibiotic prophylaxis project.
Just because a change idea may be considered hard to implement does not mean it should be a low priority. Some of the hardest changes may be the most important ones to test and lead to the biggest improvement.
How do you test change ideas through PDSA cycles?
To determine if the change ideas lead to an improvement, they each need to be tested on a small-scale using Plan, Do, Study, Act (PDSA) cycles.
PDSA cycle tests start on a very small scale (for example, testing a change on 1 patient or 1 shift or with 1 team) so you can test safely. If the first test leads to the predicted effect, the next test can be slightly larger (for example, testing on 3 patients, 3 shifts or 3 teams) and once there is more data and confidence in the change increase the test size again (for example, to 5 units).
Once you have the data and confidence from these tests, the change can be rolled out and reviewed until the team can see a reliable improvement. The benefit of this is if the change doesn't achieve the desired or expected results, you can quickly move on without having spent a huge amount of time on it or implemented it broadly.
PDSA cycles are designed to be performed rapidly and sequentially. Implementation of a change, which takes substantial time and effort, only occurs if the test of change (which starts small and gradually increases) achieve a reliable improvement.
You must work through each of the four stages of a PDSA cycle:
- Plan – the change (who, what, when, where and how) and make predictions about the outcome
- Do – carry out the plan, observe and measure (that is, collect data) what happens. Take notes of what went well and what didn't
- Study – analyse and compare data, summarise learnings.
- Act – decide on what will be abandoned, modified or tested in a larger way for the next PDSA test using the results from the study phase.
More information on PDSA cycles.
- Test no more than three change ideas at a time
- consider testing the next change idea when you are confident in the first change idea (that is, starting to scale up the testing)
- PDSA cycles are not designed to be time consuming, and can be performed rapidly and in a staggered approach
- monitor the data and measures to track improvements (refer to Data for Improvement)
- determine which changes (or combination of change ideas) are leading to an improvement and achieving the aim
- briefly document each PDSA cycle to help understand the process and ensure all four stages are followed.
Example of PDSA cycle – Changing the cefazolin vials stocked in operating theatres (OT) imprest from 1 g vials to 2 g vials
