Menu

Posts in ALM 2.0

RISK MANAGEMENT (04) – WIDELY USED METHODS

December 7th, 2019 Posted by ISO 14971, Requirements Management Tool, RISK Assessment, Risk Management 0 thoughts on “RISK MANAGEMENT (04) – WIDELY USED METHODS”

Do not know what methods can be used for Risk Management? Below is the list of methods widely used for risk management provided by the ISO 14971, ICH Q9, ASPICE Management Process.5, ISO 26262 guideline for quality risk management.

  1.   Preliminary Hazard Analysis (PHA).
  2.   Basic Risk Management Methods.
  3.   Hazard Analysis and Critical Control (HACCP).
  4.   Fault Tree Analysis (FTA).
  5.   Supporting Statistical Tools.
  6.   Failure Mode Effects & Criticality Analysis (FMCEA).
  7.   Risk Ranking &Filtering.
  8.   Hazard Operability Analysis (HAZOP).
  9.   Failure Mode Effects Analysis (FMEA).

Preliminary Hazard Analysis (PHA): This is the first trial in a system safety process. This method is applied to categorize and determine dangers/hazards, related to the operation of a proposed procedure or system

These methods can be used:

  • Early in project making when there is little information on designs or operating procedures.
  • To solve the danger types for the product class, general product type, and the specific product.
  •  Analyze existing systems or prioritize

Basic Risk Management methods: This method is widely used to hasten decisions in failed investigations and Root Cause Analysis.

The features of Basic Risk Management methods are listed below:

  • Cause and Effect Diagrams
  • Check sheets
  • Flowcharts

Hazard Analysis and Critical Control (HACCP): It is a systematic process whereby food is protected from chemical, physical, and biological danger. These dangers will make any finished product unsafe if they are left unchecked during production. Hence, the need for a design process to help reduce the risk. HACCP is useful for the following;

  • Monitoring of critical points in the manufacturing process.
  • Identify and manage risks associated with chemical, physical and biological dangers.
  • When there is a broad understanding of the process as it relates to identifying critical points (critical parameters/ valuables). 

Fault Tree Analysis (FTA): In the safety analysis, system maintainability and reliability, FTA method is widely used. It is a deductive procedure that is often used to identify both human mistakes/errors, and different combinations of software/ hardware failures that could lead to unwanted occurrences known as top events.

FTA can be used to:

  • Establish the pathway to the root cause of this problem.
  • Investigate deviations or complaints to fully understand their root cause.
  • Ensure that intended improvements will fully resolve the issue and not lead to other issues.
  • Evaluate how multiple factors affect a given issue. 

Supporting Statistical Tools: its major functions are:

  • To deal with warning limits or trend analysis.
  • Monitor critical parameters
  • Provide information to determine the process, control, variability, and capability.

Failure Mode Effects & Criticality Analysis (FMECA): It is an extension of the Failure Mode Effects Analysis (FMEA). Criticality analysis is included in the FMECA method that distinguishes it from the FMEA method. It sets the chances of failure modes against the severity of their consequences on a chart.  The FMECA methods are applied to risks and failures associated with the manufacturing process.

FMEA and FMCEA methods require the following information.

  • Recommended Actions.
  • Failure(s).
  • Causes of failure(s).
  • Effects of failure(s).
  • Functions.
  • Item(s).
  • Current Control(s).
  • Any other relevant detail.

Risk Ranking & Filtering: It is one of the easiest methods to use in risk management. 

Other names for this method include:

  • Relative Risk Management.
  • Risk Indexing.
  • Risk Matrix and filtering.

When there is a lot of complicated risk examples or possible risks in a system. With the help of Risk Ranking and Filtering, the focus can be directed to the critical risks in the system. It functions as follows;

  • To help in situations where the level of risk and its consequences is difficult to be controlled by a single tool.
  • To evaluate both quantitatively-assessed and qualitatively-assessed risks within the same organizational framework.
  • To prioritize manufacturing sites for inspection/adult by regulators or industry. 

Hazard Operability Analysis (HAZOP): It is a systematic approach that examines complicated plans, operations, and procedures. In so doing, companies can find solutions to potential risks to both equipment and personnel. 

It is used for the following;

  • Start a HACCP process.
  • Identify and manage risks associated with equipment and facilities.
  • Identify the operator or user error.
  • Identify and manage risks associated with the manufacturing process.
  • Evaluate process safety hazards.

Failure Mode Effects Analysis (FMEA): It is a systematic approach for proactively solving process issues. Hence, it will help in identifying when failure will occur and where it will occur.

Therefore, making it easier to determine which failed parts require replacement. FMEA is one of the most popular methods to use in life sciences. It helps with;

  • The monitoring of risk effectiveness.
  • Analysis of a manufacturing process to identify high-risk steps or critical parameters.
  • To prioritize risk.
  • To monitor equipment and facilities.

Quality Risk Assessment Tools Selection.          

Any of the tools highlighted in this post can be used for risk assessment. However, it can be challenging for risk management teams to decide or settle on a suitable risk management tool. To achieve an efficient QRM, it is crucial to consider flexibility in the tool selection process. 

Before choosing a risk management tool, there should be a consideration for the level of risk, the product,

ORCANOS FMEA Settings

and the process. That way you can channel both the tool and effort accordingly. Likewise, it is important to set standards and criteria for the usage of the risk assessment tool.

In the Pharmaceutical industry, the tool most experts use is the Failure Mode Effects Analysis(FMEA).

Conclusion

It is our hope that you have enjoyed our series on the introduction to Quality Risk Management. Also, having gone through this course, you come to appreciate the importance of QRM in a robust Quality Management system. The entire series covers the following;

  • The concept of Quality Risk Management.
  • The source of risk.
  • Where to apply QRM.
  • Regulatory Requirements.
  • The various types of Risk Management Tools.

Reference Links

Risk Management – orcanos FMEA Risk Management Tool
Generate Risk Management File Risk Management (ISO 14971) by Orcanos, based on FDA 2017 Recalls
Orcanos Risk Management – Add Traceability Matrix ALM Requirements Traceability Matrix Tools
10 Reasons why to use EQMS 21 CFR Part 820
Risk Management (01) – Introduction to Quality Risk Management (QRM) Risk MANAGEMENT (02) – THE BENEFITS OF FAILURE MODE AND EFFECT ANALYSIS (FMEA)

 

 

 

 

Risk Management (03) – The Regulatory Requirements For Risk Management

December 5th, 2019 Posted by Requirements Management Tool 0 thoughts on “Risk Management (03) – The Regulatory Requirements For Risk Management”

Pharmaceutical/Medical Device/Automotive Regulatory Requirements

According to regulatory bodies, medical devices, pharmaceutical or automotive manufacturers should be implementing Quality Risk Management (QRM) systems when accessing the risks that come with the production of products that introduce safety issues to the user/operator/technician of the device. In this post, we will be addressing the relevant quality standards and regulatory guidelines.

The United States Food and Drug Administration (FDA)

Below are 5 crucial points from the FDA Guidance for Industry: Quality Systems Approach to mentioned industries cGMP regulations (2006).

21 CFR Part 11 – Scope and Application 2003: This guidance is the documentation of the FDA’s approach for electronic records and signatures. They recommend that for implementation of key requirements of Part 11 they should base the decision on a documented and justified risk assessment. Also, consideration should be given toward the potential of the system to influence product quality, record integrity, and safety. 

  • Additionally, the decision to include audit trails should be based on justified and documented risk assessment.
  • The Orcanos QMS system fully complies with the regulatory requirements and it includes a built-in electronic signature and audit trail according to 21 CFR Part 11. It comes with a complete validation package to assist users to include it in their audit inspection.

 Orcanos Electronic Signature

European Regulations: There is a legal status for Annex 15 to the EU GMPs Validation and Qualification. It utilizes a risk-based process for validation of changes to components, systems, facilities, and equipment. To determine the extent and scope of validation, use a Risk Assessment Approach. It crucial to always evaluate the possible effect of changes in facilities, equipment, and systems on the product. Also, do not forget to include a risk analysis report.

In the Orcanos Design Control module, there are several tools that allow you to conduct the assessment of a change. It gives you tools to raise subspecies indicators which are based on existing traceability between artifacts or to asses risk to newly introduce change as part of the risk assessment process.

Orcanos Suspicious Effect on Change Report

There is a legal status for Annex 11 to the EU GMPs for using computerized systems. It mandates that control for computerized systems be based on a document and justified risk assessment. Likewise, the level of validation and data controls have to be in line with a proper and documented risk assessment.

Orcanos computerized system is a validated system and it comes with a validation package that is complying with the regulatory requirements for both the USA and EU.

International Conference for Harmonisation ICH Q9/ISO 14971/ISO 26262: It is regarded as the most important document when it comes to risk assessment for the pharmaceutical/medical device/automotive correlated sector.  The ICH focuses on how scientific knowledge plays a role in the protection of patients in the life industry and ISO 14971 focuses on the hazardous situation and potential mitigation while the ISO 26262 focus on safety issues related to critical components. These reference documents provides guidance on implementation processes. The three major principles that govern quality risk management are; 

  • Always use scientific knowledge were possible, as a base for evaluating risks to product quality and relate it to patient protection.
  • The extensiveness of the documentation, effort, and formality regarding risk management processes should reflect the level of risk.
  • Learn from the existing market what could go wrong in your device.

It might not always be necessary or appropriate to make use of a formal risk management process. For instance, using a well-known tool for an internal process like a standard operating procedure. Similarly, it is acceptable to use informal risk management processes or standard operating procedures for internal processes.

International Standards Organisation (ISO): The organization has three standards that address risk management. They are;

  • ISO 14971 – Medical Devices
  • ISO 31000 – General purpose risk management projects
  • ISO 31010 –  General purpose risk management projects

 

NOTE: There is a major difference between ISO 31000 and ISO 31010 despite addressing the same risk management problems. ISO 31000 highlights principles and guidelines, while ISO31010 describes risk assessment techniques.

ISO 14971: 2012 (Application of Risk Management to Medical Devices): While this document is for medical devices, the FDA recommends it to the pharmaceutical industry, others recommended it for the automotive as well. In this international standard, there is an outline that manufacturers can follow to identify potential hazards that concern medical devices. Also, it covers in-vitro diagnostic devices (IVD). Using the stipulated process, manufacturers can evaluate, and estimate the level of risk and take actions to control and monitor the risks. Likewise, the manufacturers will have criteria that will help them determine the effectiveness of the controls.

Throughout the lifecycle of any medical device, the requirements in this standard are applicable. However, it does not extend to clinical decision making, neither does it specify what risks levels are acceptable. Finally, the standard does not mandate that manufacturers use a quality management system. Nevertheless, a risk management system is a crucial part of the quality management system.

Reference Links

Risk Management – orcanos FMEA Risk Management Tool
Generate Risk Management File Risk Management (ISO 14971) by Orcanos, based on FDA 2017 Recalls
Orcanos Risk Management – Add Traceability Matrix ALM Requirements Traceability Matrix Tools
10 Reasons why to use EQMS 21 CFR Part 820
Risk Management (01) – Introduction to Quality Risk Management (QRM) Risk MANAGEMENT (02) – THE BENEFITS OF FAILURE MODE AND EFFECT ANALYSIS (FMEA)

 

RISK MANAGEMENT (01) – INTRODUCTION TO QUALITY RISK MANAGEMENT (QRM)

November 23rd, 2019 Posted by Requirements Management Tool 0 thoughts on “RISK MANAGEMENT (01) – INTRODUCTION TO QUALITY RISK MANAGEMENT (QRM)”

Are you new to the ISO 14971:2012 & FMEA system or seeking to improve your processes?

As a QA representative or Functional Safety Manager, you will find in the following series of posts all the knowledge you need to get started implementing GDP for your Risk process.

 

FMEA Risk Management

RISK Summary Report

Overview

Quality Risk Management is the evaluation of product quality and risk to patient / passenger / doctor / nurse / operator health or anyone that may be exposed to safety issues when using the device based on data, scientific knowledge, and data. According to regulators, when using a lifecycle approach to implement either an informal or formal risk tool in line with ISO 14971 or ICH Q9 (Pharma) or the Automotive used of the FMEA. The Quality Management System (QMS) should incorporate Quality Risk Management (QRM) for the following purposes:

  • Acceptance of Residual Risks
  • Risk Assessment
  • Communication of Identified Risks
  • Risk Review
  • Risk Control

What will we be covering this series of posts discussing the QRM?

In this series of posts, we will be covering the following topics;

  1.     The concept of Quality Risk Management (QRM).
  2.     How to identify the source of risk.
  3.     Possible areas to apply QRM application.
  4.     Regulatory requirements.
  5.     Risk Management Tools.

People that will benefit from learning Quality Risk Management include people in the following departments:

  • Risk Management
  • Quality assurance
  • Engineering Service Providers
  • Commissioning
  • Product Development
  • Compliance
  • Project Engineers and Managers
  • Validation
  • Manufacturing Operations and
  • All Management related departments should be aware of QRM.

Modules

In this series of articles we will cover 3 module categories which include;

  1.     Introduction to Quality Risk Management (QRM)
  2.     Regulatory Requirement
  3.     Risk Management Tool

Glossary

It is crucial to understand the terms that often appear when discussing Quality Risk Management, hence the need for a dictionary. Some popular terms are;

  • Corrective Action (CA): The action to take to correct a deviation.
  • Critical Control Point (CCP): A point in the process where you can apply a control measure to either remove or reduce to an acceptable level a (pharmaceutical) quality hazard
  • Failure: When an item fails to work as it should work.
  • Failure Mode: How the item failed.
  • Failure Mode and Effects Analysis (FMEA): It is a technique for determining fail modes and their effects. It addresses possible scenarios of what causes failure for low-level components and its impact on the system or application.
  • Failure Modes, Effects, and Criticality Analysis (FMECA): A way of adding an analysis of criticality of severity, detectability, and occurrence of FMEA.
  • Fault Tree Analysis (FTA):  A technique that analysts use to trace the source of failure in a high-level system.
  • Hazard Analysis and Critical Control Point (HACCP): A systemic approach for identifying, evaluating, and control of food safety hazards.
  • Harm: Physical damage to people, environment, and property.  
  • Hazard: A possible source of harm.
  • Hazard Analysis: A way of determining relevant information on the potential hazard to food and how to address it in the HACCP plan.
  • Preliminary Hazard Analysis (PHA): A way to identify hazards and design solutions for them.
  • PIC/S: It stands merely for Pharmaceutical Inspection Convention and Pharmaceutical Inspection Co-operation Scheme.
  • Probability of Detection: Estimating the chances of detecting a hazard before it causes harm to the patient.
  • Risk: It is the presence of potential harm as well as its severity.
  • Risk Acceptance: The choice or decision to accept risk.
  • Risk Analysis: The ability to use the information to identify hazards and estimate the risk
  • Risk Assessment: The process of gathering the information that justifies the actions to be taken to manage risk. The process will involve risk identification, analysis, and risk evaluation.
  • Risk Communication: The process of sharing information on risk that exist between stakeholders and decision-makers.
  • Risk Control: The process of reaching a decision that would allow for risk management with the system. In the process, there will decisions on how to identify the risk, measures to take, timeframe, and much more.
  • Risk Evaluation: A way to compare risk criteria to the risk estimate in order to reach a level of acceptance.
  • Risk Identification: A way of using the available information to identify potential hazards in a system or application.
  • Risk Level: A quantitative measure to evaluate the degree of risk in a system.
  • Risk Management: a systematic way of using policies, procedures, and practices to address the tasks of identifying, analyzing, evaluating, control, and monitoring of risk.
  • Risk Priority Number: The total measure of risk in a system. It is evaluated by multiplying severity with the rate of occurrence. The higher the number, the higher the risk in the system.
  • Risk Reduction: Actions that are taken to reduce both the probability and severity of risks.
  • Risk Review: A way of monitoring the outcomes of various risk management plans and strategies.
  • Risk Treatment: The process of selecting and implementing measures to change risk.
  • Risk Management Master Plan (RMMP): A framework that applies to all projects, and it can be used to draft a risk management plan.
  • Risk Management Project Plan (RMPP): This applies to individual projects and the plan specific to that project.
  • Severity: The measure of effects of a hazard

Now that we have covered the list of terms used by the QRM system, we can start to see how they are working together. We will identify events and actions around some of these terms and allow you to practice them in the ORCANOS QMS system.

 

Reference Links

Risk Management – orcanos FMEA Risk Management Tool
Generate Risk Management File Risk Management (ISO 14971) by Orcanos, based on FDA 2017 Recalls
Orcanos Risk Management – Add Traceability Matrix ALM Requirements Traceability Matrix Tools
10 Reasons why to use EQMS 21 CFR Part 820

 

Passing MDSAP with no paperwork

November 10th, 2019 Posted by Requirements Management Tool 0 thoughts on “Passing MDSAP with no paperwork”

MDSAPOrcanos has passed the MDSAP audit successfully with one of its leading medical device customer, led by Irit Bouwman.

Irith testified that this was a very successful audit, done purely online. “I was impressed of how powerful the tool is, it was as easy as clicking a button to get the information I needed, during the audit…..

“You are the first company I gave 0 grade since I have started giving audits on MDSAP…” said the auditor for STEP I

As Irith Bouwman, Director of QA with over 20 years of experience explained, the MDSAP audit is a very unique audit in a way that it takes both the standard of the ISO 13485:2016 together with the regulation of the regions the company is about to act and making sure that the SOP reflects those regulations in the SOP.

The lowest the grade is the better your audit. Grade Above 4 it is not recommended to go to stage II. If there is missing regulation in the SOP the grade start from 2, and more points are added during the audit finding.

In addition, during the audit, there is a new factor added to the audit grade is the RESPONSE TIME of the organization to request of the auditor. In that sense, it usually gives 10 min to retrieve a document from the quality system. During the audit, the retrieval time that it took our customer was less than 30sec. You may see the auditor put a stopper on the desk during the audit.

The reference to documents is also tested and the revision of the documents and the obsolete management of documents. Orcanos e-DMS system serves all those requirements electronically with almost zero human interaction and 0 errors.

Orcanos is proud to serve some of the leading medical device manufacturers, helping them to move their paper-based quality management system into an electronic template-based system, thus saving time and money  and reduces overall cost.

Get your MDSAP audit-ready today www.orcanos.com

cGMP – DESIGN AND DEVELOPMENT TRANSFER (DMR) (11)

November 6th, 2019 Posted by Requirements Management Tool 0 thoughts on “cGMP – DESIGN AND DEVELOPMENT TRANSFER (DMR) (11)”

The Device Master Record (DMR) is the ultimate document for ensuring efficient design transfer. It is not a mandatory requirement according to ISO 13485. The DMR is mostly theoretical as it is a compilation of documents required to complete the design process. The documents consist of all the documents above and the validation master plan.

DMROrcanos DMR system

In time, the document will need revising and subject to change. The DMR will help index each document as well as their note their current revision. To achieve a successful design transfer, you need the DMR. The transfer could be an internal transfer, manufacturing, or involving a customer manufacturing organization (CMO).

There are several ways to capture the design transfer process. They are;

  • A transfer checklist
  • A checklist that forms a part of the product’s lifecycle SOP.
  • An entirely new form.

The checklist comprises of activities to complete to aid a successful design transfer.  The list will include the following;

  • Facility preparedness
  • Product specification
  • Training activities
  • Test method
  • Component properties
  • SOPs and WIs
  • Success criteria

Also, the design transfer process comes with a design transfer plan with well-defined criteria. A report should be made available upon completion. The report will contain all the activities and proof a successful transfer.

ORCANOS in MEDICA during 18 – 21 November 2019 in Düsseldorf

October 19th, 2019 Posted by Requirements Management Tool 0 thoughts on “ORCANOS in MEDICA during 18 – 21 November 2019 in Düsseldorf”

Medica 2019

ORCANOS In Medica During 18 – 21 November 2019 In Düsseldorf

MEDICA is the world’s most significant event for the medical sector. For more than 40 years it has been firmly established on every expert’s calendar. There are many reasons why MEDICA is so unique, making it the largest medical trade fair in the world.

During the dates of 18 – 21 November 2019 ORCANOS will be present in the MEDICA event, ready to meet with you. Whether you are exhibiting or visiting we would like to meet with you. We can discuss the ORCANOS software solution for QMS and Product Development (ALM).

One System. Multiple Processes. Zero Faults. We are coming to give you a chance to see for your eyes, ask questions and listen to our customers presenting in the Medica show.

To arrange a meeting with us contact:

VP Sales & Marketing

Rami Azulay

email: rami.azulay@orcanos.com

mobile/whatapp +972-54-444-0255

or just fill the form for request for a meeting here:

 

— Await you in Düsseldorf. Visit our website: www.orcanos.com[

CAPA Chapter V: Reviewing The CAPA System and Actions

October 19th, 2019 Posted by Requirements Management Tool 0 thoughts on “CAPA Chapter V: Reviewing The CAPA System and Actions”

Overview

The FDA and the ISO13485 both demand that the management reviews the status of all PAs and CAs. People tend to ignore the importance of review, and that can be costly for the management. It is up to the management to take responsibility for the CAPA review process.

Reviews should not be restricted to the management alone since it can be done at several stages of the CAPA process. For instance, a weekly review will help the management get a better understanding of the CAPA status. Needless to say, it is crucial that there is a review to ensure success. Orcanos system allows the organization to proactively send alerts regarding the review process and keep the management up to date in real-time.Management Review

Inputs for Management Review

There is a significant difference between data for management and data for day-to-day management. Below are some of the duties of a manager when reviewing the status of CAPA. They are;

  • It is the duty of the management team to provide sufficient resources.CAPA Resource Allocation Review
  • Ensure that all actions are following the set plan. That way support is made available for CAPA activities.
  • To produce a form that allows for the closure of CAPAs. Ensure that actions are complete and there is data to support it.CAPA eForm

Orcanos CAPA eForm

 

Actions that Yield Effectiveness

Closure can sometimes be mistaken for completion. However, completion means that the actions taken were effective. One of the few ways to fall into a non-compliance trap is to set a fixed date of CAPA action completion. Obviously, fixed deadlines are a bad idea, especially for actions that will require auditing reviews. Not with the Orcanos CAPA system. It allows you to separate between the CAPA completion to the PA/CA completion.

Perhaps, there could be an assumption that one audit is sufficient, but that may simply be one consideration point. There could be multiple measure points that will need for multiple reviews. Well, multiple data points tend to yield better results. An example is dealing with registration audits that often require at least 2 audits that span roughly two years.

Another reason to have multiple action points is that you get to see the result of actions outside that of CAPA. Deadlines for completion are within control when there is a good relationship between the assigners and assignees. Unless your system can proactively prompt the assignee with messages on its upcoming commitment for completion, exactly what the CAPA system will generate automatically.

It is important to distinguish between the closure of CAPAs and the closure of actions. Always leave room to be flexible, that way you can see the completion of action within a reasonable schedule. Remember that the completion of actions is a way to determine effectiveness.

 

CAPA Chapter IV: Actions To Take To Address CAPA Problems

October 11th, 2019 Posted by Requirements Management Tool 0 thoughts on “CAPA Chapter IV: Actions To Take To Address CAPA Problems”

CAPAIf you discover a non-conformity in your CAPA system is systemic. It means that the non-conformity is realized and it will keep recurring. Then it is time to take action to both correct it and prevent it from recurring.

Hence, it is suggestive that for every CA there is a PA component. It follows the logic of definitions for Corrections, Preventive Actions and Corrective Actions.

For all actions, it is crucial to define, analyze for effectiveness, implement and document them.  

Actions (Going beyond what to do)

To get a full picture of how actions affect the CAPA process, then follow the steps below.

  • Documentation: Always document every action and if need be, refer to the documentation requirement guide.
  • Define Completion Criteria: You have to find a way to determine if an action was successful. If not, it would be impossible to know if an action was completed. 

    For instance, how will you know if an action to improve product feature or process is complete? Or perhaps your action was meant to reduce a shipping error. There should always be a way to measure your actions.

  • Verification: Using the shipping error example, how would you verify the completion of a sipping process? One way will be to contact the customer and ask if they got their item. Their answers will help verify the shipping process.
  • Effectiveness: It is not uncommon that they may be some error. In the shipping example, a way to determine effectiveness is to ask how often customers get their order correctly. The answer will provide insight into the effectiveness of your process. However, while some processes can allow for error, processes that involve risking lives have to be 100% effective.

Good Practice to Follow

We will outline a standard practice to follow for action items. They are;

  1. Always make someone responsible for the entire process. There is a chance of victim-blaming if the process becomes a group responsibility. While teamwork is essential, make sure someone heads the group.
  2. Set realistic deadlines. A deadline that is too optimistic can lead to failure. Therefore, work with the owner and ensure to pick a deadline that will allow you to complete the process.
  3. Always partner with the owner and an expert that might be needed to complete a particular step in the process.
  4. Have frequent meetings to ensure that everything is working according to the plan and on schedule. The frequency of meetings should align with the risk that comes with the process. Risky processes demand more status updates. Meetings will help you measure progress.

The Tipping Point for Actions

While Root Cause Analysis might be the most prominent issue when it comes to the CAPA system. Actions also lead to a significant amount of issues in the CAPA system. In our earlier blogs, there are hints to how actions can constitute a problem.

Sometimes when actions are set and the sequence doesn’t reach completion, it will create problems in the CAPA process. The situation is common in instances where the project demands outweigh the CAPA problems.

Furthermore, manager ignoring CAPA has a priority make taking action problematic. Although, frequent meetings can help bring the problem to light if the manager bothers to host them.

Another way for problems to arise is when there are no completion criteria despite defining the problem. The person in charge of taking action has to understand the importance of completion criteria to prevent delay. Alternatively, if the scope of the action isn’t well defined, then the same problem will arise.

Project owners can be anxious and push for quicker deadlines, it is up to the assigners to convince owners on unclear or unreasonable deadlines. Likewise, it is important that all parties are in agreement on all data collection and various deadline.

CAPA Chapter III – Root Cause Analysis of the CAPA System

October 1st, 2019 Posted by Requirements Management Tool 0 thoughts on “CAPA Chapter III – Root Cause Analysis of the CAPA System”

Introduction

Root Cause Analysis (RCA) is the heart and soul of the CAPA system. Without defining the root causes or cause of a problem, it would be nearly impossible to prevent from recurring. According to Wikipedia, root causes are the result of a causer chain where a sequence of events leads to problems. 

Also, there is a possibility that someone is responsible for introducing the error. Furthermore, there is the puzzle of why the error was not detected.

Root Cause Analysis

One of the easiest ways to carry out a root cause analysis is to reiterate that the problem is the root cause. Although, this is a terrible approach and will often not lead to the discovery of the root cause. For example, it is easy to simply blame documentation for a process gap. 

Likewise, one could easily blame specification for an error in an equipment part, while there is a possibility that other parts could have problems too. The truth is that there is never just one root cause, there are several.

Hence, the process of discovering the root cause or cause is both a science and an art. A lot of creative thinking goes into the process of identifying all likely possibilities for a root cause. Data plays a vital role in ensuring that you reach the right conclusions. When conducting RCA, it is a great idea to consider various perspectives.

The hardware team mostly believes that all problems stem from software and the software team thinks that the problem stems from hardware. Similarly, R&D and manufacturing trade blame. As a result, it is important that the management team take control of the situation and stick to the facts when investigating problems.

It is worth mentioning that one could argue that all problems are management problems. A good management team will avoid blame shaming and remove emotions from their decision making. By sticking to the facts, the management team will be able to get to the root cause.

The Toolbox for Root Cause Analysis

There are several toolboxes available to help determine root cause and there are several factors that would help decide on what toolbox is right for a specific problem. For example, a fault tree analysis will suit a technical problem issue, while a 5 why approach will work for a quality system problem.

A tool is only as useful as the person using it. A great tool can be misused in the wrong hands and vice versa. Therefore, when it comes to resolving issues in the CAPA system, it is best to go for skilled and experienced personnel rather than a recent hire. 

A quick search for an example of root cause analysis will often return the Jefferson Memorial Example. The park service investigates the root cause of why the memorial building was deteriorating.

The Jefferson Memorial Example

Similar to the time when Jefferson and his trumps had to defend American from British invasion, the park service is defending the building from destructive invaders. Apparently, the stones in the building were falling due to frequent washing.

The frequent washing was the result of excess bird dropping, and excess birds were attracted to the spider food source in the building. The spiders came to feed on the thousands of tiny insects in the vicinity. The tiny insects were drawn to the evening spotlight at the monument that coincides with the time the insect goes into a mating frenzy. 

As a solution, the parking service opted to delay the time of that they switch on the light to one hour after sunset. The result is the reduction in the number of insects by 90%, which in turns breaks the food chain that results in the frequent washing of the building.

The example above is a great example of ensuring that you have all the information relating to the problem before taking any action. In so doing, you will get to the root cause of a problem and then solve it.

The 5 Why Analysis Example for Root Cause Analysis

The “5 Why” model can be used to explain the building’s deterioration. Without further asking why the park service could have spotted at reducing the amount of washing after discovering that the washing is the cause of the deterioration. However, by reducing just the amount of washing, the memorial building will remain unsanitary due to the bird’s poo. 

The investigation going by asking why could have stopped at bird poo without further questions. But by continually asking why, the parking service was able to discover that the root cause was the light. By discovering the root cause, they were able to implement effective corrective action at a much lower cost.

The Result

After arriving at the root cause, it becomes obvious that implementing a solution at this point will yield the best result. For instance, by delaying the switching on of the light by one hour, what will be the result? There would be fewer insects, then less food, then fewer birds, and reduced washing. The example shows the chain effect of both the problem and the effect of the solution.

While the example above seems a bit straightforward, that is not always going to be the case. The “5 Why” analysis will require the skill and experience of a veteran in the CAPA system to help plot the path to the right conclusions. Having an electronic system such as Orcanos that includes the e-CAPA system is exactly that way to pass knowledge on to the next generation of people as well to collaborate the information across departments.

The Major Tripping Point of the CAPA system.

The RCA is often the point that problems in the CAPA system begin. It is easy to think that the problem is the cause or to assign blame to someone. While a person might be the reason for causing a problem, unless there is a maliciously intent, then you need to find the root cause. The practice of going for the easy solution or blame shaming isn’t acceptable.

In the Jefferson example, it is easy to find several points where the investigation could end before reaching the root cause. Also, always document the Root Cause Analysis process, else one can assume that there was never a problem. It is important to document your RCA process as it would help reviewers and auditors understand the steps that led to your conclusions.

Conclusion

Never reaching the root cause of a problem is the same as plugging a hole in a dam, when there are several linking points. Blaming people especially when there is no proof of malicious intent is frowned upon. Likewise, simply relying on tools to solve the problem is not enough. Tools just make the process of finding a solution easier, as the tool will require the skill and experience of a veteran to be effective.

Accept all inputs and opinions as it would enable you to gather all the facts and discover the root cause without bias. Lastly, don’t just settle on one cause keep investigating until you discover all root causes.

CAPA Chapter I: Understanding Non- Compliance in the CAPA System

September 16th, 2019 Posted by Requirements Management Tool 0 thoughts on “CAPA Chapter I: Understanding Non- Compliance in the CAPA System”

One of the most recurring issues that the FDA finds during its inspection is the non-compliance to the Corrective Action Preventive Action (CAPA) system. Surprisingly, the non-compliance problem isn’t recent as it continues to be a problem for most companies. The registrars’ audit reveals a couple of factors that contribute to the non-compliance trend. They include:

  • The lack of identification of root causes: Most companies often stop their investigation after finding a cause even if it is not the root cause. While others will repeat their findings as to the root cause for the non-compliance.Not Implementing CAPA Quickly: In the process of focusing on product development, some companies tend to forget to apply CAPA. Likewise, CAPA may not be a priority for some companies or they lack adequate resources to implement CAPA.
  • Lack of Understanding of the CAPA Process: There is a possibility that the company may not understand how CAPA works. As a result, they apply processes that are not in compliance. Also, when they implement CAPA, some lack the drive to follow through with the process and access its effectiveness.

  • Managers Ignoring CAPA: Some managers might not consider CAPA as a realistic solution. There are managers who feel that the application of CAPA will be a waste of resources and time.

One of the ways to address to fix the issue of CAPA compliance is commitment. It is not enough to have good intentions, the management has to demonstrate a willing commitment towards ensuring compliance.

Process Requirements

Here are some factors that ensure compliance based on regulation requirements..

Process Documentation: The idea of documenting the CAPA process is very beneficial to the company. In so doing, the company can be sure that they cover every part of the process while making sure that everyone can follow the same steps. 

Also, the company can ensure that everyone has the same understanding of the CAPA process as most CAPA concepts do not have a specific definition. For example, the FDA maintains a universal set of activities for the CAPA process. Hence, the FDA is able to have a single CAPA process.

On the other hand, ISO 13485 splits the CAPA into different categories the CA and PA. Despite the fact that both processes have different procedures, there is an overlap between 21 CFR 820 and ISO 13485.

FDA Process Requirements

As stated earlier, the FDA has just one single process for CAPA. The process requires the following;

Analysis: Critical analysis of the problem.

Investigation: A thorough search of the root causes of the problem.

Actions: Take steps to both correct and prevent the problem. Therefore, making that they won’t be an issue in the future.

Verification: Proof that the steps taken have an effect on issues. There should be answers to questions like; did the actions taken have the desired result? Are there any adverse effects to the actions taken?

Procedural Changes: Making sure the changes are institutionalized.

Communication: To inform everyone about the changes and make sure that they are aware, they act on it, and they understand it.

Review: Informing the management of the current changes and getting their approval on the changes.

Documentation: Always make sure that everything is documented. As a result, there will be a trail of events for all changes and activities.

All can be achived using Orcanod electronic CAPA system.

ISO 13485 Process Requirments

ISO 13485 has two separate processes for both CA and PA. According to ISO 13485, the processes for CA are as follows:

Review: The review process for CA is similar to the analysis process given by the FDA. It involves the understanding of the problem.

Identification of Causes: It is the same process as the FDA’s identification of the root causes process.

Need for Action: Taking steps to fix the problem and making sure they don’t reoccur.

Determine Actions: While it is similar to the FDA’s requirement to take action, the focus here is ensuring that the actions appropriate.

Record Result: Similar to the process of documentation in the FDA’s process.

Determine Effectiveness: It is the same as going through the verification process on the FDA requirement.

For PA, the procedures overlap with that of CA. However, since preventive action means that there are no non-conformities yet, then there is no need to take any action. The following are the procedures for PA;  Identification of causes, need for action, determine actions, record results, and determine effectiveness.

It should be noted that in the need for action for PA, while it is similar to the procedure for CA, there is no need for correction. Likewise, when determining effectiveness, care should be taken that there is no regression.

In conclusion, it is obvious that there are similarities between CA and PA. Also, there are similarities between ISO and FDA requirements.

In that sense, the Orcanos eQMS system is easily adoptive which allows powerful tools that are easy to use and configure to meet your current and future needs in the same system.

Page 1 of 6
1 2 3 6
Orcanos

Contact

8 Tozeret Ha'aretz Street
Tel Aviv, Israel
+972-3-5372561
info@orcanos.com

Copyright © Orcanos, All rights reserved. | Privacy policy | Terms of use