Posts by Rami.Azulay

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


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


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:[

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”


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”


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.


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 II – Driving Source

September 21st, 2019 Posted by e-GMP, ISO 13485, Recall 0 thoughts on “CAPA Chapter II – Driving Source”

Often times, we suspect products and process as the main sources for CAPA. However, there are several other areas that we can consider as CAPA sources. They include;

  • Customer Complaints: It represents a majorly of all product-related sources for CAPA.  In the event that the customer complaints are repetitive, then there is a chance that the root cause can keep recurring. Also, complaints about the system are an indication that there is a problem with the training or instruction.
  • Yield Rates: Yields rates are most likely the main cause of CAPA rising in the manufacturing industry. Systemic issues become unavoidable when there are frequent expulsions in the process limit.
  • External and Internal Audits: Audits are the biggest identifiers that there should be a process PA or CA in the system.
  • Employee Feedback: The feedback from employees could help prevent process issues as well as enhance product development in the future.  Employee feedback is one of the direct sources a company can use to implement CAPA.
  • Vigilance: Another great resource for CAPA is to remain abreast of competitors in the same field. You can study your competitor’s product to try and implement steps to prevent certain likely problems that may arise in your product. For example, you learned that pumps develop a free flow problem by studying your competitor’s pumps. You can hereby take steps to eliminate the problem in your own pumps. We at Orcanos conduct daily research on every recall that is reported by the FDA site and conducts a technical analysis to allow the share of such events with our customers.

Managing Risks

Subconsciously most people find themselves managing risk by prioritizing their daily tasks and giving more effort to tasks they consider more important. Similarly, CAPA requires the same approach.  The actions to be taken should be prioritized based on risks. The reasons to apply such a strategy are;

  1.  To prevent the company from wasting resources on trivial problems.
  2.  To continue to create an opportunity to respond to public safety concerns.
  3.  The risk will help determine the approach of the investigation. For instance, you could take a scientific approach like the FMEA or FTA when dealing with patients safety. Meanwhile, a five-why approach can be used to address process issues.
  4. Always document your risk-based decisions.

The Process

In taking a closer look into the CAPA process, we will be expanding on the key requirements. They include;

  • Analysis
  • Investigation
  • Determining action
  • Implementing action
  • Determining the Effectiveness

First Thing to Consider: Understand

The step in the CAPA process is understanding. Without understanding the issue, it will be impossible to find the root causes or determine appropriate action. In the event that you do implement appropriate actions, there is a chance that actions and the changes would not be as comprehensive as they ought to be.

However, there are steps to take in order to understand the problem. The steps include;

  1. Defining the problem as well as writing it down. In so doing, you can better grasp the starting point of the issue.
  2. Try to identify the cause of the problem. A simple tool to use is the Fishbone Diagram.
  3. Using the Fishbone Diagram you have to determine if people, machinery, environment, process, material, and management are contributing to the problem. While you might not be solving the problem at this stage, you will be gaining a better understanding.
  4. The scope of the problem is the next step in the process.  For instance, perhaps you are using a piece of particular equipment to manufacture several parts. Unfortunately, there seems to be a fault with just one part.

Regardless of the fact that the other parts created using the same equipment have no faults, you should consider the possibility that the equipment could be contributing. Likewise, there could be a documentation problem. The ability to analyze scope ensures that you identify all the root causes.

In the event that a problem escapes detection, then it is important that there be an investigation as to why it wasn’t detected.  Perhaps there were no early-stage checks or the current checks are ineffective. 

The importance of early-stage checks is vital in the software industry where late-stage errors can prove to be costly. For example, an error that is not fixed in design stage can be 3 times or more expensive to fix at the verification stage of the process. Therefore, best to think of the early stages where the problems could be fixed and document them.


When you discover a non-conformity in a product, then it is time to exercise damage control. The damage control is not to divert the financial burden, but to ensure that the product does not cause harm to patients. If the product is already in the market then issuing a call-back and inform the customers to prevent more damage is the best course of action. 

However, if the product is still in the inventory, then the containment action will be to quarantine the inventory until the problem is solved. Containment actions should always match the risk as the damage control for issues that will affect customer’s health will differ from actions that have to deal will function or form.

Scope Analysis

Below is the summary of the thought that should go into scope analysis.

  1.  If a product is affected by equipment, then what other products are affected by the same equipment?
  2.  How thorough is your quality control system if a process is missing a particular document?
  3.  Are there audit gaps or any other gaps?
  4.  Are all of your software system validated? Is your validation process complete?
  5.  Do components affect the quality of your system and what role does your supplier play?

In conclusion, if you do not fully comprehend the extent of a problem in the CAPA system, then there is bound to be some missteps along the way.

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.

CAPA: Corrective and Preventive Actions Introduction Principles

September 11th, 2019 Posted by Requirements Management Tool 0 thoughts on “CAPA: Corrective and Preventive Actions Introduction Principles”

Corrective and Preventive Action (CAPA) is a way to improve the company’s processes. They are a series of actions that eliminate unforeseen events and causes of non-conformities. Likewise, CAPA, as a concept falls under several ISO business standards and Good Manufacturing Practice (cGMP).  The primary focus of CAPA is focusing on the root causes of specific problems and risks. In so doing, it can help ensure that they won’t be a need for either corrective action or preventive action in the future. This article aims to help you understand the CAPA process within a regulated environment.


The outline on the subject of CAPA is as follows;

  •         Background
  •         The current State of CAPA
  •         Process Requirement
  •         Process Analysis
  •         The CAPA status review
  •         Conclusion


Two major forces drive the CAPA system. In the US, there is the Food and Drug Administration, the federal regulations, Title 21 Part 820 Subpart J, and CAPA Section 820.100. Meanwhile, companies in the EU that accept the ISO 13485 standard for the quality system there is the Section 8.5.2 corrective action and Section 8.5.3 preventive action. It is worth mentioning that 820 will be known as 21 CFR 820, and 13485 will be EN ISO 13285:2016. Also, there is not of a difference between the old 13485 standards of 2003 and the updated version of 2013 but there are some changes on the 2016 edition when it comes to CAPA requirement.

It is a requirement for both the US FDA and ISO 13485 that CAPA procedures be documented. In the descriptions for CAPA in both organizations, they both address non-conformities.

Regulatory Confirmation

The eligibility criteria for a CAPA system mandate that a situation of non-conformance or a risk of having it. The common suspects for non-conformance issues are either components, products or something physical. However, processes are also suspect despite being less obvious. Regulations often demand that organizations follow specific processes when collecting or analyzing artifacts. Non-conformities are bound to happen when processes are ignored, and there is no collection of artifacts.

CAPA has two distinct components, namely, corrective action and preventive action. Corrective action is used to address systemic non-conformities when they occur. Meanwhile, preventive actions help to address the risk of non-conformities that are likely to happen. In that sense, an electronic system such as Orcanos must let you conduct traceability to CA/PA activities as well to RISK and its mitigation.  

Image1: Orcanos Traceability from/to CAPA


Only About Compliance?

There are pivotal debates regarding the CAPA system. There is an argument that if there is a systemic non-conformity, then action should be taken to identify why and take action to fix and prevent the occurrence in the future. On the other hand, companies find preventive actions problematic. It is not unusual that companies take precautionary steps frequently in the form of reviews, prototypes and much more. However, rarely do they run the steps through the preventive action process.

Despite CAPA and DR (Design Review) and report topping the list, it is difficult to ascertain the safety and effectiveness of products considering the high rates of recalls. A non-scientific approach to the various findings reveals that there is a lack of understanding when it comes to the CAPA approach. The result leads to a lack of implementation. For example, stating that all CAPA will be closed in 60 days in the CAPA Standard  Operating Procedure (SOP) is wrong. The action further demonstrates a lack of understanding of the CAPA process. Inspectors are left with no choice other than issuing findings to processes that they can’t implement or follow.

Therefore, this article will be highlighting realistic ways to approach the CAPA process. The hope is that it will reduce any form of self-damage when it comes to findings and equip you with tools that will guide the regulatory compliance of your business. Eventually helping you making a choice to move onto some electronic form of system to manage the CAPA complete process.

The Basics of Corrective Action

Corrective Action is the first section of the CAPA. Identification of non-conformities tends to trigger corrective action. Although, the language in 820 when addressing CA is cause for confusion as it stipulates action to eliminate recurrence. There will be clarity on the subject further down the line.

The Basics of Preventive Action

Preventive Action (PA) represents the other half of CAPA. It becomes actionable in situations where there is a risk for non-conformities, and no steps are in place to mitigate such risks. It is worth mentioning that while in the 13485 standards, there is a distinction between CA and PA. While in 820, there is no such distinction when it comes to CAPA. 

We stated that PA is a frequent feature as part of a company’s project risk activity. The activities often include design and review for manufacturing, preventive maintenance and much more. However, the challenge is identifying when to apply preventive action.

Key Concept

The inconsistent use of terminologies is to blame for the problems in the findings of the CAPA system. To correct this notion, we will be using some easy to grasp terminology in the absence of standard definitions.

  • Corrections: They are actions taken to resolve problems like replacing a faulty capacitor in a circuit board. Another example is fixing a software bug that alters the user’s input.
  • Corrective Actions: Actions that helps ensure that a problem will no longer occur. For example, changing your capacitor supplier cause they supply faulty resistors to a more reliable supplier. Alternative, training a programmer on a concept that they made an error while working.
  • Preventive Actions: Actions that will stop a problem from happening. An example is reviewing a capacitor’s rating before use to estimate the likelihood of fault. Alternatively, set up a coding standard that programmers can use to review their code to prevent problems.

 Systemic Issues

It would not be efficient to flood the CAPA system with every issue. As an alternative, only system issues should be in the CAPA system. Now, the question becomes, what is a systemic issue? In simple terms, it refers to problems that will keep happening without any intervention. System issues can manifest in the following ways;

  • Quality: Missing procedures in the quality process.
  • Product: Failure that keeps repeating.
  • Manufacturing: Out tolerance results that don’t stop.
  • Process: Missing steps or lack of actionable steps.

Non-Systemic Issues

By describing non-systemic issues, we better understand the difference between it and systemic issues. Non-systemic issues are problems that are likely to happen once or possess low recurrence probability. When dealing with processes, fallouts are not unusual. Therefore, having fallout that is within the limits of the process makes the problem non-systemic. Checking trends and frequency of a problem occurring is the best way of determining if it is non-systemic. However, if you have a non-systemic and non-conformity problem, the action is required.

Some of the best practices will involve checking the trend of all non-conformities, and assessing non-conformities to determine the disposition. Orcanos eQMS system includes a Non-Conformities eForm that will allow you to report and measure your NCR. 

Systemic Issues Product Examples

Below are a few examples that showcase system issues in products.

  1. Should the door be open, an infusion pump will not prevent free flow. The free flow is a systemic issue as the door opening with a set installation will not stop people from seeing the patient.
  2. Cross-contamination of duodenal scopes is responsible for a spate of infections. The reason is that the scopes were not cleaned properly to prevent infection. The problem might have fallen under non-systemic issues if it happened just once. However, the frequent rate at which the infection keeps occurring makes it a systemic issue.
  3. After several testing, making parts that do not match their corresponding mating part as per specification. The rate at which this error occurs and the fact that it surpasses the process limit makes the error systemic.

Systemic Issues Process Example

Problems can come from other factors like processes rather than the product.

  1. When an audit reveals that the quality system failed to incorporate a CAPA requirement. For example, a means of assessing the effectiveness of corrective action. The problem becomes systemic if the process is already reviewed, approved and documented.
  2. An FDA inspection revealing that a company does not keep a record of customer complaints and then issues them a 483. The problem is systemic if the people responsible for taking the call do not realize that all customer related calls should be recorded.

On our upcoming post about CAPA, we will give more tools and tips about how to improve the handling of the CAPA process and be more effective.


cGMP – Design and Development Master Validation Plan (10)

July 15th, 2019 Posted by Requirements Management Tool, Test Management, Validation and Verification 0 thoughts on “cGMP – Design and Development Master Validation Plan (10)”

People in the medical device industry are often wary of the term validation even though they shouldn’t. Validation is using objective evidence and experiment to ensure that a set of requirements are met when testing for product or service usage. Furthermore, as it pertains to device validation. The objective is to match the specifications with user needs and application. Therefore, validation is proof that using a specific process to manufacture a device will meet both device requirement and user demands.

Validation is the building block for verifying the quality of a product. As a result, the product that is tested during validation must represent the final product. According to ISO 13485, companies must keep a record of the product they use during validation.

Validation MVP

In the same way that the design control process starts with a plan, validation must take the same approach.  The plan is often extensive, covering several areas earning the name Validation Master Plan (VMP) or Master Validation Plan (MVP). It is best to always start the validation plan early in the design process. The plan should be able to pinpoint what will help satisfy the criteria like;

  • Methodologies
  • Performance properties
  • Validation activities

Likewise, there should be a review of the validation plan to avoid risk and deficiencies.

“The First Article”

The first article is the common name given to the first set of products. They are either serialized batch or initial batch (Validation batch). In some cases, validation reports help to document the properties of the first articles. Also, there could be a separate first article report. Forgetting to include labeling and packaging as part of the validation process is a common oversight.

It is crucial that companies include packing in their validation plan. Its effect of product performance is enormous and difficult to measure.  Some packaging can give off electrostatic charge or cause the material to leach into a sterile product. Therefore, testing the packaging can help prevent such occurrences. Similarly, the validation plan should include labels. Environmental conditions can cause labels to fail, leaving the product bare and unbranded.

Inclusion of clinal trials in the product validation is optional and depends on the type of product. Nevertheless, there should be some form of clinal evaluation just in case. Also, validation should account for the worst possible scenarios using simulations that mimic the conditions that the product will face. Some possible simulations can test for the following;

  • Vibration and shock
  • Temperature
  • Humidity
  • Other tests will account for either transportation or storage of the product.

Finally, validation should take into account the following customers/users;

  • Operators
  • Patients
  • Caregivers (nurses/doctors)
  • Other relevant parties


Orcanos Master Validation Plan

Related Links

Page 1 of 13
1 2 3 13


8 Tozeret Ha'aretz Street
Tel Aviv, Israel

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