My father used to always tell me: build your first house and destroy it, then build your second house and sell it, and finally live in your third house. There is a lot of wisdom in these words because people tend to make a lot of mistakes when they build something for the first time.

The same is applicable for implementing a CAPA (Corrective and Preventive Action) module for the first time, in this article I will highlight the most important things to consider to build a CAPA that lasts:

1.      Not every issue is a CAPA

 As part of the implementation, if you design CAPA so that it is used to record any quality issue, then it becomes an overwhelming process that everyone hates. There will be a large number of issues that need to be worked on, regardless of their priority and severity.

The better way is to allow recording and containing all quality issues outside the CAPA process. A risk based approach should be followed to decide on the issues that require a CAPA that goes through the whole process of digging for the root cause and deciding on an action plan to prevent reoccurrence.

2.      Navigation to related records

A CAPA could have multiple sources, it could be created as a result of a customer complaint, internal quality issue, audit, or other records within your QMS. It can also result in creating other records within your QMS like tasks for your resolution plan, new (or revised) policies and procedures, and many other things.

Your implementation should allow for creating these records from each other (for instance you should be able to launch a CAPA from a Complaint), and the underlying platform should allow linking records automatically. If you end up doing linking manually (or not linking records at all), that could lead to serious traceability issues that make your CAPA module unusable.

3.      Analytics, Analytics, Analytics

 You continually improve your Quality Management System with each CAPA you close, because you implement a plan to prevent recurrence. This is a big benefit.

However, the huge benefits of CAPA, can be achieved after you grow the data in it, that data is very valuable. Huge quality improvements can be achieved if you can understand the trend of the issues that happen and understand their major causes. That will give you a huge opportunity to focus on improving the things that matter most.

You should take great care in selecting the underlying platform before you start your CAPA implementation, if the platform does not provide an Analytics tool that can integrate in real time and on the fly with your data and configurations, then you will be just looking at an outdated copy of your valuable data without being able to understand what is really going on.

If you are implementing a CAPA that actually works and can last, you have to account for the fact that your data will grow and could become massive. The last thing you want is an Analytics solution that would slow down your Quality System each time you run it on your big data. Just as bad, is to have to copy your data somewhere else so that you can analyze it. Analytics should be REAL TIME and ON THE FLY.

4.      Suppliers Engagement

 The quality of your product is affected by the quality of materials and services delivered to you by your suppliers, and you will need to issue a SCAR (Supplier Corrective Action Request) in many cases. For instance, when there is a Major Nonconformity as a result of an Audit, or when you get a material or service that is not in-line with the agreed to specifications or SLAs.

The majority of CAPA implementations do not fully automate the process of issuing a SCAR. In these implementations the issue is recorded in a CAPA module, and then communicated to a Supplier using an email requesting a response and action plan, the Supplier would then record it in their own system, and communicate back by email (again). In these implementations Quality Teams on both sides suffer to keep the information in sync regarding what needs to be done, meet due dates, and write progress updates. This is the most critical issue that you should avoid in your CAPA implementation.

Again, it all starts with the selection of the underlying platform, some platforms promise a solution for this issue, but these solutions do not address the problem entirely and correctly. Here are some examples of how the problem is being addressed incorrectly:

• Supplier Portals: These portal solutions will usually be a system other than the system you’re using for your QMS, requiring huge efforts to automate and synchronize data between the two system.
• Supplier Users: Which is a way of allowing you to add user accounts for suppliers within your cloud QMS, this is problematic too as you have to pay for the supplier’s user licenses (to account for the bad quality they provide in many cases).
  
  

The ultimate solution would be a compliance network that allows multiple companies to interact inline, where suppliers are able to respond to your SCARs without paying for user licenses, but also gives suppliers the option to increase their footprint while being responsible for licensing. Suppliers will likely be happier with using such platforms, as they can use the same account to respond to their multiple customers in the same place.

5.      Configurability:

If you would like a CAPA Implementation that endures, it should be easy to change it frequently. There will always be a need to change the CAPA process as your business evolves and your QMS implementation matures.

This would also go back to the underlying platform that you are using, and whether it allows you to do configuration changes or not. A typical platform would provide you with a set of tools, that any business user can use to re-configure without involvement from developers or technical teams.

The last thing you want is to have to deal with a vendor that sends you a “techy” consultant for a few weeks, and leave you with thousands of lines of configuration scripts (code) to deal with when you don’t have a clue on how to modify them.

A CAPA implementation that endures, is a CAPA implementation that evolves.

6.      Compliance

Some industries (Such as Life Sciences) have to comply with standards and regulations as part of their CAPA implementation specifically, and the QMS in general.

Your implementation becomes a very complicated project if you onboard your CAPA on a platform that is not validated. You would typically want to leverage validation done by the platform provider and focus your validation effort on the configuration you implemented (Process Qualification).

If you find yourself in a situation where you are trying to handle compliance requirements as part of your CAPA implementation (example FDA 21CFR requirements), then you are probably on the wrong platform, stitching fixes to account for what your platform provider didn’t embed will usually result in a failed CAPA implementation.

7.      Configuration Management:

 Following the best practices of configuration management will help a lot. You should always implement in Dev, Test/Validate in QA, then roll out your changes to Production.

The platform you are using should provide a really easy way for you to copy your configurations at each stage of your project. If you are redoing the configurations manually, you could end up with errors in Production, and the future maintainability of your CAPA will be questionable.

CAPA Implementation that endures, should allow you to roll out changes to production seamlessly and frequently.

Finally, it is obvious from the points above that Implementing a CAPA module that endures with you for years to come depends a lot on the selection of the underlying platform. It is always advisable to do the selection exercise carefully before you start implementing, and if you are already using a platform that does not provide you with what you need, it might be time for a change.