When is an issue a CAPA (Corrective and Preventive Action) request?

[Plowmaster]

I work in start ups (medical device) There is always a bit of an art to deciding what goes into the CAPA system and what doesn't. Often when an issue is seen as more as a 'development' issue it will be part of development. (And if you have worked in start ups, you'll know every single one is manufacturing and developing at the same time as they push scale up)

So, If you created a CAPA procedure for a company that doesn't have a full QMS in place yet. (Also in start ups, its not that quality activity isnt going on, the efforts are just in islands. Everyone is resource constrained and often by the time you hear of a problem, the 'experts' have created a solution and moved on.) How would you define guidelines for when an issue should be a CAPA given a rapid development environment.

Thanks,

-K

 

[Stijloor]

I work in start ups (medical device) There is always a bit of an art to deciding what goes into the CAPA system and what doesn't. Often when an issue is seen as more as a 'development' issue it will be part of development. (And if you have worked in start ups, you'll know every single one is manufacturing and developing at the same time as they push scale up)

So, If you created a CAPA procedure for a company that doesn't have a full QMS in place yet. (Also in start ups, its not that quality activity isnt going on, the efforts are just in islands. Everyone is resource constrained and often by the time you hear of a problem, the 'experts' have created a solution and moved on.) How would you define guidelines for when an issue should be a CAPA given a rapid development environment.

Thanks,

-K

Can someone with Medical Device expertise help?

Thank you!!

Stijloor.

 

[somashekar]

I work in start ups (medical device) There is always a bit of an art to deciding what goes into the CAPA system and what doesn't. Often when an issue is seen as more as a 'development' issue it will be part of development. (And if you have worked in start ups, you'll know every single one is manufacturing and developing at the same time as they push scale up)

So, If you created a CAPA procedure for a company that doesn't have a full QMS in place yet. (Also in start ups, its not that quality activity isnt going on, the efforts are just in islands. Everyone is resource constrained and often by the time you hear of a problem, the 'experts' have created a solution and moved on.) How would you define guidelines for when an issue should be a CAPA given a rapid development environment.

Thanks,

-K

You have to differentiate which is the design and development changes in progress before the product release and after the product release.
A good design and development process will most certainly reduce the "issue" that you state.
Per ISO 13485, you have to establish a documented procedure for feedback system to provide early warnings of quality problems (which perhaps you term as issue) for input into CAPA process.
Typically you will also see that medical device version will undergo quick revisions when changes becomes necesary based on CAPA, and these CAPA gets triggered from early warnings. These are in situations when design processes fail., perhaps from the lack of complete design input or lack of design and development verification / validation ...

 

[Plowmaster]

Thank you for the reply. Start - ups are still a slightly different animal, regardless of regulations or standards. None of them I have encountered have a 'Good design and development process' what they have is Project management with experts simply trying to get the next task done, and fix problems as they come up. Most start ups in silicon valley will do what it takes to get a 510(k) through. However, the state of the quality system will be very lacking and by the time they are scaling up there are a # of design changes to the product different than the submitted design in the 510(k). (As long the intended use doesn't change)

So in this evironment, the first thing I do is establish document control to start getting processes documented. Next the CAPA system but the are a myriad of issues, some go into CAPA and some don't, but it's a bit of an art to decide what goes in. Often, issues that would be a CAPA are solved before I even hear about it. (Solved on an immeadiate fix level, so it's no longer of interest given people have 1000 things to do and bandwidth for 100.) So if their first introduction to a QMS is simply something that slows them down, compliance is very low. You still have to teach the company at the same time and the QMS has to add value for people to proactively interact with it. (Unless its stict compliance, Authorative vs Tacit, but authorative often brings minimal compliance)

So, I guess I'm seeking general thoughts, what kind of criteria / guidelines would you write into your CAPA procedure as to when something should be submitted for CAPA. Right now, I review each issue and make a decision on each one. It would be nice to have a published set of guidelines. (Although admittedly, this doesn't garantee anything, but none the less would be helpful when management asks: What goes in to the CAPA system and what doesn't)

Thanks,

-K

 

[somashekar]

some go into CAPA and some don't, but it's a bit of an art to decide what goes in. Often, issues that would be a CAPA are solved before I even hear about it.

The art is to be sensitive to pick those which are systamatic in nature and which can potentially repeat (in sense you know that if you do not take some steps at some place, the problem will reappear)
This does not include blunders .....

Often, issues that would be a CAPA are solved before I even hear about it.

You did not hear them ... so there is nothing ...
If you keep hearing similar issues time and again then it is systamatic.
What is systamatic can be analysed and a root cause can be found and then CAPA becomes effective.


If your big fishing net is made of fine netting then you catch many small fishes as well. You cannot enjoy all of them when you want to fry them for your lunch. Let the netting be bigger and matching to the size of the net, so that the catch is big few and the fry is tasty and wholesome.

 

[yodon]

Somashekar hit the nail on the head: use whatever filter you can to identify only systemic issues. Don't overwhelm the CAPA system with the normal issues you encounter during design. If you suspect that you may have systemic issues in design, use a separate issue tracking system to document them. You can then review the list to see if there are, indeed, any systemic issues. For example, after requirements are baselined, track the number of changes to the document(s). You might see a trend indicating that your requirements definition / review process is not sufficient. If your testers continue to find the same problem, there may be an issue with your CM process.

If it's too much a burden to have folks document such issues as they are found and corrected, maybe just meet with them informally to gather the data. Remember, the CAPA system is about fixing or improving the process.

Since you say you have each issue, consider sorting them into process-related categories. If you see one stack really growing, that's a pretty good indication that you have a systemic issue. If one stack only has a few, then it's likely that process is rather stable with only a few bumps along the way. As you start looking at the issues through process "glasses" I expect you'll start to see those trends and get a better idea of what should be a CAPA (candidate) versus what is just continuing to move through the normal development process.

 

[Plowmaster]

Thanks for the input!

I'm doing more or less the things you have mentioned. I guess there is not a complete clear of simple way to answer the question I get 'So how do you decide what goes into a CAPA?' Part of it is genuine inquiry, as CAPA is a knew concept for some of the management. When you explain what it is, the lines are still fuzzy for them what goes in and what gets put on the watch list. I bascially put a lot of issues on the watch list and circle back around to see whats happened with the issue. The onesy twoesy of development I simply let the engineers / scientists solve and move on.

Thanks,

Kendal