Error Management, RCA

2,513 views
2,404 views

Published on

Root Cause Analysis

1 Comment
2 Likes
Statistics
Notes
  • Dear author!
    How to download this?
    Please teach me or share me at truongchi.simer@yahoo.com.vn
    Thanks!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
2,513
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
0
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide

Error Management, RCA

  1. 1. ERROR MANAGEMENT<br />RCA, 5WHYs & CAPAs<br />CAP Accredited <br />ISO 15189 Accredited<br />Prepared By Bilal Al-kadri<br />Feb, 2009<br />
  2. 2. Objectives<br />To provide participants with a guide for best practice in handling errors.<br />To educate participants on how to:<br /><ul><li>Define the problem
  3. 3. Understand the 5 whys method to determine root cause
  4. 4. Plan and implement actions
  5. 5. Verify effectiveness of actions implemented
  6. 6. Recognize the benefits of corrective & preventive actions.</li></li></ul><li>What is Error?<br />Is it a mistake? wrong action? problem? ignorance? inattention? failure? accident? incident? negligence? carelessness? slackness? deviation? deficiency? wandering? deviation?etc…<br /><ul><li>Error: Nonconformance, unexpected or unplanned deviation from standard policy or procedure, usually attributable to human or system problem.</li></ul>Consider Error as a Learning Opportunity <br />
  7. 7. Used Terminology<br />Error = Nonconformance<br /><ul><li>OER = Occurrence Error Report
  8. 8. CAs = Corrective Actions
  9. 9. PAs = Preventive Actions
  10. 10. RCA = Root Cause Analysis
  11. 11. QA = Quality Assurance
  12. 12. GDP = Good Documentation Practice</li></li></ul><li>How to handle Errors?<br />Document the error <br /><ul><li>Describe the problem
  13. 13. Report the error
  14. 14. Take immediate action to contain the error
  15. 15. Investigate the error
  16. 16. Find the likely cause of the error.
  17. 17. Take CAs to correct the error
  18. 18. Take PAs to prevent recurrence of the error.</li></li></ul><li> Document the error <br />Use available in-house forms (OER) form # ULC/EROR001 <br /><ul><li>Do not use scrap paper, sticky notes, agenda, notebooks, etc…
  19. 19. Write with a pen,NEVER a pencil, AVOID whiteouts</li></ul>.<br /><ul><li>Write Lab Name, Department Name, Initiated By, Date and Time.</li></li></ul><li>Document the error<br />Document the error right after occurrence<br /><ul><li>Do Not depend on your memory
  20. 20. If it is NOT documented it is NOT done
  21. 21. Documentation is to be complete and legible.
  22. 22. Data should be recorded in a manner that may be clearly understood by an outside auditor.</li></li></ul><li>Describe the problem<br />Be specific and not too detailed.<br /><ul><li>Briefly describe the problem, time of occurrence, name of equipment and/or test being used as available, any other related clear-cut info.
  23. 23. Do NOT mention names of patients or employees. </li></li></ul><li>Describe the problem<br /><ul><li>Use specific and accurate descriptors for what occurred, rather than negative and vague words.
  24. 24. Avoid words such as, I, He, She, poorly, inadequately, haphazardly, carelessness and complacency.
  25. 25. Do not pinpoint fingers at anyone.</li></li></ul><li>Report The Error<br />Errors are not secrets <br />I shall report to my supervisor<br />Immediately report the error to your supervisor.<br /><ul><li>Ensure that OERs (after initiation) are forwarded to your supervisor & QA.
  26. 26. Ensure that OERs are signed by your supervisor and not just left behind.</li></li></ul><li>Take immediate action<br />Immediate action is really a description of what was done after the problem or event was discovered. <br /><ul><li>What actions were taken to contain the problem and stop & end it right away from continuing? </li></ul>777<br />
  27. 27. Take immediate action: Examples<br /><ul><li>ThermometerXY was in use and not calibrated?
  28. 28. Remove XY & segregate from other thermometers.
  29. 29. No documented procedure addressing AB requirement.
  30. 30. Write a procedure addressing AB requirement.
  31. 31. Inadequate instructions in a procedure.
  32. 32. Update the procedure accordingly.</li></li></ul><li>Investigate the error<br /><ul><li>Assign Responsibility & Resources to investigate the occurrence of error; (this may require one individual or a team, depends on the complexity of the error.</li></ul>Review & discuss all circumstances related to the problem and must consider:<br />
  33. 33. Root Cause <br />After the problem/event is contained, the causes must be identified to prevent recurrence. <br /><ul><li>Proximate cause (s) are the source that directly results in the nonconformance.
  34. 34. Contributing causes also called Intermediate causes are those that may not have sufficient power to result in the event taking place. 
  35. 35. Root Cause is simply the last logical cause in the chain.</li></li></ul><li>Why, Why, Why, Why, Why<br />is the smart question… own it!!<br /><ul><li>Requires thought
  36. 36. Promotes additional research
  37. 37. Enhances problem solving skills
  38. 38. Does not assume there is one right answer
  39. 39. Avoids predetermined answers
  40. 40. Stimulates discussion
  41. 41. Empowers the person answering</li></li></ul><li>Five Why’s Preparation<br />Five why’s is a Root Cause Analysis Tool Not a problem solving technique. <br />The outcome of a 5 Why’s analysis is one or several root causes that ultimately identify the reason why a problem was originated. <br />
  42. 42. Five Why’s Preparation<br />Corrective <br />Action(s)<br />Problem<br />Root Cause<br />Follow up<br />Preventive <br />Action(s)<br />
  43. 43. Five Why’s Preparation<br />Any 5 Why’s must address 2 different problems at the same time: <br /> (“Why made?”) ? (“Why not detected?”) <br />Other Root Cause analysis Tools:<br /><ul><li> Ishikawa Charts (Fish Bone)
  44. 44. Design of Experiments
  45. 45. Is / Is not Analysis
  46. 46. Cause & Effect Diagram.
  47. 47. Statistical Data Analysis (Cpk, ParettoCharts, etc…)</li></li></ul><li>Five Why’s Preparation<br />Even though the discipline is called 5 Why’s is not always necessary to reach 5 before the root cause of a problem is fully explained; or it may take more than 5 why’s to get to the bottom of it. It will depend on the complexity of the problem itself. <br /><ul><li>In any case, 5 has been determined, as a rule of thumb, as the number at which most root causes are clearly identified.Follow your thought process and let it decide how many Why’s you require to get to the point where the root cause is evident. </li></li></ul><li>For all the Five Why’s:<br /><ul><li>Ask the full question including the problem or cause behind it. If there is a problem with rejected specimen AB : </li></ul>“Why was AB specimen rejected?” <br />If the answer is no request form was submitted:<br />“Why no request was available ?”<br />
  48. 48. 5 Whys<br />Invented in the 1930’s by Toyota Founder Kiichiro Toyoda’s father Sakichi and made popular in the 1970s by the Toyota Production System, the 5 Whys strategy involves looking at any problem and asking: “Why?” and “What caused this problem?” <br /><ul><li>Six Sigma, a Quality Management System (QMS), uses “5 Whys” in the Analyze phase of the Six Sigma Define, Measure, Analyze, Improve, Control(DMAIC) methodology. </li></li></ul><li>Five Why’s Preparation<br />It is said that a well defined problem is a half resolved problem; John Dewey <br /><ul><li>Hence it is important to state the problem as clearly as possible.
  49. 49. Define the problem as in terms ofrequirements that are not being met. </li></li></ul><li>Five Why’s – The First Why<br /><ul><li>Often this 1stWHY must be a short, concise sentence “problem” that obviously explains the reason.
  50. 50. It is Okay to write it down even if it seems too obvious for you. (It may not seem that obvious to other persons that will read the document).
  51. 51. The answer to the 1st WHY will be the proximate cause (s) to the error. </li></li></ul><li>Five Why’s – The Second Why<br /><ul><li>Get into the technical arena, the explanation can branch out to several different root causes here. </li></ul>It is OK to follow each of them. <br /><ul><li>The first two why’s have prepared you to focus on the area where the problem could have been originated; </li></li></ul><li>5 Whys, Key points<br />Use to get to the root cause, NOT to solve the problem<br /> Correcting a symptom, wastes resources <br /> Correcting root cause gets rid of problems permanently<br /> Watch out for Bias<br /> Find the right person to answer your questions <br /> Dot to rely only on the 5Whys for critical problems<br />
  52. 52. Five Why’s – The Third Why<br />Do not jump to conclusions yet, follow the regular thought process even though some underlying root causes may start surfacing already. <br /><ul><li>This 3rd why is critical for a successful transition between the obvious and the not so obvious. the last three why’s will take you to a deeper comprehension of the problem.
  53. 53. You may be missing the obvious by rushing into “logical” explanations”.</li></li></ul><li>Five Why’s – The Fourth Why<br /><ul><li>This is a good time to include a Cause & Effect analysis and look at the 5 M’s.
  54. 54. Method
  55. 55. Materials
  56. 56. Manning
  57. 57. Machines
  58. 58. Mother Nature</li></li></ul><li>Five Why’s – The Fifth Why<br />When you finally get to the fifth why, it is likely that you have found a systemic cause. Most of the problems in the process can be traced to them. <br /><ul><li>If you have reached the fifth why and you are still dealing with process related cause(s), you may still need one or two more why’s to deep dive into the systemic cause. </li></li></ul><li>Five Why’s – Conclusion<br />A good way to identify if the 5 Why’s was done properly is to try to organize the collected data in Something like: <br />“Problem Description” occurred due to “Fifth Why”. This was caused by “Fourth why” mainly because “Third Why” was allowed by “Second why”, and this led to “First Why”. <br /><ul><li>If this cannot be done or the sentence is fragmented or meaningless chances are that there is gap between one or several of the why’s. You then must revisit the 5 Why and identify those gaps to fill them in. </li></li></ul><li>Five Why’s – Benefits<br />Simplicity.  It is easy to use and requires no advanced mathematics or tools. <br />Effectiveness.  It truly helps to quickly separate symptoms from causes and identify the root cause of a problem. <br />Comprehensiveness. It aids in determining the relationships between various problem causes. <br />
  59. 59. Five Why’s –Benefits<br />Flexibility.  It works well alone and when combined with other Quality Improvement & Troubleshooting techniques.   <br />Engaging.  By its very nature, it fosters and produces teamwork and teaming within and without the organization. <br />Inexpensive.  It is a guided, team focused exercise.  There are no additional costs. <br />
  60. 60. Five Why’s<br />One final point to ponder:<br />After root cause has been determined, move on to the corrective actions, preventive actions.<br />You may follow up to verify the effectiveness of CAs and PAs as necessary.<br />Close out OERs<br />
  61. 61. Exercise, Duration 20min<br />An error has occurred in your area(or outside); Use OER form to report the error.<br />Hints:<br />_ Describe the error;<br />_ State your immediate action;<br />_ Investigate, Use the 5Whys to find the root cause; <br />_ Write down CAPAs;<br />
  62. 62. Summary<br />Errors are ways to improve.<br />Errors in medical labs are systematic and/or human<br />Identify the problem clearly and keep in mind why it happened? And why not detected?<br />Report errors upon occurrence<br />Use the 5whys efficiently & don’t jump into conclusions<br />Knowing the Root cause = Implementing correct CAPAs<br />
  63. 63. Contacts<br />Bilal Al-kadri<br />iso15189.consultant@gmail.com<br />

×