Guidelines on continuous quality improvement

1. Introduction
2. Continuous quality improvement
3. Assessments that could be undertaken as quality projects
4. Quality assurance programs
5. Quality project resources
Appendix

 

1. Introduction

1.1. Quality improvement can be defined as “an organised process that assesses and evaluates health services to improve practice or quality of care”. Quality Improvement is a term often used to describe a “cycle of quality”

 

The core principles of a quality improvement program are:

  • Continuous improvement.
  • Consumer focus.
  • Incident prevention.
  • Universal responsibility.

1.2. The objective of quality programs is to ensure that high standards of clinical practice are maintained through regular reviews. The results of such reviews should be evaluated and actioned as necessary.

 

1.3. All pain medicine physicians and trainees should participate in quality activities, including regular attendance at quality meetings.

 

1.4. Quality programs must evaluate clinical care and be used to improve standards when required, ensuring consistency with accepted professional standards, including relevant policy documents issued by the College.

 

2. Continuous quality improvement 

Continuous improvement is the term to describe improvement occurring in in incremental steps. It never stops. Continuous improvement is the process to ensure processes are continually improved.

The steps in the continuous improvement process are as follows: 

  • Have a specific improvement program with a specific goal.
  • Define the improvement process.
  • Define variability and problems in the process.
  • Find the root causes of the problem.
  • Recommend improvements.
  • Implement, monitor and evaluate the improvements.
  • Continuous improvement process must be driven from the top, but implemented from the bottom. 

Staff who are assigned to project improvement teams need to understand the processes for conducting improvement projects.

PDCA CYCLE

PDCA Diagram

 

 

Plan - A change or a review aimed at achieving an improvement. 

  • In this phase, intended improvements should be analysed, looking for areas that hold opportunities for change. To identify these areas for change, the use of a flow chart or Pareto chart should be considered. 

Do - The change or improvement (preferably on a small scale) should be carried out.

The change decided in the plan phase should be implemented.


Check or Study – The results. What was learned? What went wrong?

 

This is a crucial step in the PDCA cycle. After the change has been implemented for a short time, it must be determined how well it is working. Is it really achieving the improvement as hoped? This must be decided on several measures that can be used to monitor the level of improvement. Run Charts can be helpful with this measurement.

 

Act - The change should be adopted, abandoned, or run through the cycle again.

 

  • After planning, implementing and then monitoring a change, it must be decided whether it is worth continuing with this. If it consumed too much time, was difficult to adhere to, or even led to no improvement, aborting the change may be considered, before planning a new one. However, if the change led to a desirable improvement or outcome, expanding the trial to a different area, or slightly increasing the complexity may be considered. This recommences the Plan phase and can be the beginning of the continuous improvement process.

 

3. Assessments that could be undertaken as quality projects

3.1. Staff:

3.1.1.1 Numbers and qualifications, including senior, junior, nursing, technical and secretarial staff.

3.1.1.2 Appointment criteria, credentialing procedures, allocation of duties and levels of supervision.

3.1.1.3 Workload and conditions of work.

3.1.1.4 Staff well being as assessed by health, morale and occupational safety record.

3.2 Physical facilities:

3.2.1.1 The working space for all clinical and non-clinical activities.

3.2.1.2 Equipment, including compliance with standards, preventive and other maintenance and replacement.

3.3 Financial aspects of the Unit, including: 

3.3.1.1 Budgets.

3.3.1.2 Expenditure. 

3.4 Unit teaching programs. 

3.5 Unit research activities. 

 

4. Quality assurance programs

 

Quality assurance programs may include:

 

4.1 Review of management, including budgets, expenditure and cost effectiveness.

 

 

4.2 Criteria based audit: this is a performance evaluation according to predetermined criteria (usually reported outcomes of peer groups). In areas without published criteria, new criteria can be established by original study or by a consensus of peers. Performance in relation to ANZCA Clinical Indicators in acute pain is an example of a criteria based audit.

 

 

4.3 Clinical guidelines, policies or protocols: these are recommended methods of clinical practice. pain physicians should check for compliance with guidelines, policies or protocols and regularly review them.

 

 

4.4 Critical incidents:  these are voluntary reports by staff on events that led to, or could have led to adverse outcomes in patients or staff members. A program must analyse the incidence, causes, contributing and mitigating factors and outcome of critical incidents.

 

 

4.5 Risk management:  these are actions to reduce risks to patients and staff in pain medicine. A risk management program undertakes the identification of risks, the assessment of risk factors and the control of risks.

 

 

4.6 Peer reviews:  this is the evaluation of clinical performance by peers. Areas to review include oain history recording and legibility, compliance with respect to attendance and treatment, outcome to interventions including procedures, physical therapy and psychological techniques.

 

Main methods are:

4.6.1 Participation in mortality and morbidity meetings.

4.6.2 Reviews of randomly selected cases.

4.6.3 Review of a pain medicine specialist’s practice.

4.7. Patient surveys: these are satisfaction surveys of patients. A program could survey satisfaction with communication, involvement of significant others, improvement in quality of life and pain levels, informed consent, use of opioids. Issues such as confidentiality and patient anonymity should be addressed.

 

4.8 Root cause analysis: this is an analysis of systems errors associated with Pain Medicine including pain management practices, with participation in institutional quality assurance (QA) activities focusing on root cause analysis.

 

Benchmarking with similar units should occur to compare outcomes and adverse reactions. This could include comparison to available national databases.

               

4.9 Follow-up reviews: Quality programs should be include follow-up reviews to ensure that remedial steps are taken wherever problems are identified. The quality programs themselves should be reviewed to ensure that this follow-up is included.

5. Quality project resources

Formally constituted pain medicine units should appoint a quality co-ordinator, normally for a period of two years, with eligibility for re-appointment. The quality co-ordinator will be responsible for the implementation and supervision of the quality activities. Appropriate time, secretarial and other support should be allocated to this co-ordinator.

 

5.1 The quality co-ordinator should ensure that Faculty guidelines are implemented within the limits of the size of the unit. 

Appendix

How to carry out a continuous improvement project 

There are many ways to carry out a continuous improvement project. A generic approach is described here, which should suit most situations. No projects are the same and so the approach should be tailored to fit the job. 

 

These are the main steps:

 

1. Set up the project team

 

The steering team will have defined the terms of reference, selected the team leader and given some general directions about the composition of the project team. A team is more effective than an individual for problem solving because it can draw on a wider range of experience and skills. 

 

2. Define the scope 

The project team should review the scope of the project. 

The scope of the project includes the statement of the problem, a definition of the boundaries, the magnitude of improvement goals, a target date for completion and the resources available. 

One of the fundamental approaches of continuous improvement is to look at the process “from the customer’s point of view”. The starting point should be to find out what they want. 

There may be several perspectives to consider. The patient may not be the only “customer”. There may be perspectives from several parts of the treatment process, or even external to it that are important to consider. The goal should be to define those whose point of view is relevant, to find out their expectations, and to meet them. 

Firstly, the team should talk to those who use the service, find out how they come about doing this, what problems they have with it and how the service can be enhanced. 

The information obtained from these interviews should be analysed to determine which aspects of the service could be improved and the extent to which the service meets the needs of those using it.  

The team should then define the project goals. 

The team should develop a very clear understanding of what is expected from the project. The goals should be quantified and used as a benchmark to measure any success. 

 

3. Understand the process

 

The next step is to understand how the treatment process presently works. Before the project team can attempt to improve on this, it must understand how it works at present and what it is supposed to do. There are two approaches to understanding the present process. One is descriptive; the other is graphic.

 

Process description  

A good way to understand a process is to describe it. One benefit of describing the process is that it sometimes leads to the discovery of obvious problems and solutions that can quickly be fixed. The team should ask and answer key questions: 

  • What does the process do?
  • What are the stages of the process?
  • What are the starting and finishing points?
  • What are the inputs and outputs?
  • Who are the providers and the users?
  • Who uses the service and who pays for it?
  • Are there obvious problems with the process? 

 

Flow charts 

A flow chart of the process is particularly helpful in obtaining an understanding of how the process works. It provides a visual picture. There are two types of flow charts that are particularly useful. The first is a top down flow chart and the second is a deployment matrix flow chart. 

 

A top down flow chart shows only the essential steps in a process without detail. It focuses on the steps that provide real value. It is particularly useful in helping the team to focus their minds on those steps that must be performed in the final ‘improved’ process. 

A top down flow chart is constructed as follows: - by first listing the main steps across the top of the page and then listing the subsidiary steps from the top down, below the main steps. The details are not recorded. For example, rework, inspection, and typing are omitted. 

The flow chart provides a picture of the process that the team can work on and simplify. It allows people to focus on what should happen instead of what does happen. 

Usually, most processes have evolved in an ad hoc manner. When problems occur, the process is fixed. The end result is that a simple process has evolved into something complex. A flow chart is a first step to simplification. 

 

A deployment matrix chart is another type of flow chart. This is useful because it shows who is responsible for each activity, how they fit into the flow of work and how they relate to others in accomplishing the overall job? 

To construct a deployment matrix flow chart, the major steps in the process are listed vertically down the left hand side of the page and the people or work groups are listed across the top. The process is then charted to show who does what. 

 

4. Plan the project

 

There is no ‘right’ way to tackle a project. There are many ways and some will work better than others. The basic plan of action will be to:

 

  • Identify root causes.
  • Develop solutions.
  • Implement the changes.
  • Review the results.

 

 

5. Determine information needs

 

Based on the project goals the team should review what information is needed to analyse the problem.

 

For each goal, the team should determine what information is needed to understand how well the process is working. They need to know what information is available, what is not available and how to collect the information that is not presently available.

 

6.  Choose the tools for the job

 

There are a variety of tools that can be used, these include:

 

  • Time plots.
  • Control charts.
  • Brainstorming.
  • Consensus cuilding.
  • Cause and effect diagrams.
  • Structure trees.
  • Pareto charts.
  • Six questions.

7. Identify the root causes 

Use brainstorming, cause and effect diagrams or the structure tree to develop a list of possible causes. Begin by defining the problem, and then generate ideas as to the cause. 

To get at the root cause, ask the question ‘what is the cause of the cause?’ For instance, if some sections are defective, find out why. Maybe it is due to a provider problem. Ask why again and keep asking “why?’ until the team cannot think of another question to ask. 

When the team has developed their opinion as to the root causes, it should verify the conclusions with data. 

The team should think about why it is collecting data and what data it needs to verify the conclusions. It is easy to draw the wrong conclusions from erroneous data. Use charts and graphs to analyse the data and have the conclusions checked by others who are knowledgeable in the process. 

If there are obvious root causes that can be fixed easily, then fix them straight away. 

 

8. Develop solutions 

The ideas for solving the problem should be evaluated against criteria to determine the best solution. The team should define the characteristics of an ideal solution and identify the criteria that must be satisfied and the criteria that are desirable, but not absolutely necessary. 

 

Constraints to a proposed solution should be identified. A constraint is a factor that limits the selection of a particular solution. These constraints may take the form of budget limits, rules or practices that may make a solution difficult to carry out. 

Each possible solution should be evaluated against the criteria for selection. The team should seek to develop a solution which comes closest to solving the root causes, remains the easiest to implement, satisfies the criteria for selection and does not impact on the constraints.

 

There may be occasions where the team identifies constraints that, in fact, are not real constraints. The team may find some flexibility if it pushes hard enough to have such ‘constraints’ removed.

 

When the team has selected the best alternative, it should obtain feedback from those who are most affected by the changes.

 

Depending upon the nature of the changes, it may be possible to implement these immediately. Alternatively, it may be necessary to present the recommendations to the steering team to obtain approval before they can be implemented.

 

9. Implement the solutions

 

The team should use the "plan, do, check, act" sequence to implement the proposed changes.

 

Define exactly the changes to be made. Generate a list of activities that need to be done to accomplish the objective and then decide the steps required to implement the changes.

 

A schedule of activities should be prepared and milestones defined so that progress can be monitored. Responsibilities for each of the action steps should be defined.

 

Be sure that all those who are affected by the changes are properly informed and briefed on the reasons for the changes and that they understand how the changes will take place.

 

It is sometimes better to implement the changes on a pilot basis rather than make a wholesale change across the board.

 

10. Review the results

 

Monitor the effectiveness of the changes and compare the results with the original goals of the study. Ask the following questions:

  • Did the team achieve the expected benefits?
  • Were there any unexpected benefits or problems?
  • What can the team learn from these?
  • What can be done to fine tune the solution so that it can be applied on a wider basis? 

11. Standardise the change

 

If the improvement project has been successful with one process, it should be refined and applied to other similar processes. One should not waste time setting up further improvement teams to re-invent the wheel. 

Copyright © Australian and New Zealand College of Anaesthetists.