CAPA Process for a small Software company - Ideas and recommendations wanted

[Micked]

Hi fellow cove dwellers,

I am designing a light weight and efficient QMS for a *very* small SW company. Most CAPA threads seem to very HW oriented.
If you go by the book you would have different procedures, and possibly tools, for problem reports, customer complaints, CAPA, incident reporting etc.
This is simply out of the question for my client, they would never make it work in practice.

What I am thinking of is to use one tool for "issues" from many sources, from simple internal bugs to adverse event reporting.
The tool will have provisions, check boxes and information fields, that will support the different processes.
As an example, a prototype version has a checkbox: "Risk analysis needs to be updated" [Yes, No, Not checked (Default)] This way I want to force them to make active decisions.

The only thing I have to do is to write a SOP to guide them through the "issue" handling and prescribe what steps have to be taken for different classes of issues. The current prototype uses ["Simple bug", "Larger change that needs document changes", "Documentation change", "Adverse event"].

The C and P in CAPA would simply be decisions in the "issue" handling process.

Any thoughts on my approach?

[Jennifer Kirley]

Hello,

I got hung up on the HW and SW. Can you elaborate please?

[Micked]

Hi,

I clearly see the point of a traditional CAPA process for mechanical and chemical products. There you would normally do some statistical trending, and then take appropriate action.
Let's take an example. If I get a lot of returns on ball bearings, I could start an investigation on lubrication, correct polishing of the bearing balls etc. From that you would infer if corrective and possibly preventive actions are needed.

If I deal with a pure SW product it is a bit different, at least to my simplistic mind.
"Returns" are usually bug reports in this case. To me it seems a bit over the top to analyze bugs for:
- Specification errors (preventive action is better training in writing specifications?)
- Coding errors (Corrective action is to fix the bug? Do I have to make a CAPA investigation for this? Preventive action is training in coding rules?)

And, in my case where there is one (!) programmer in the company, what is reasonable to do there?

That is why I want to create one simple to use and simple to understand system for everything from internal bug reports to customer complaints.

I think this is a question of general relevance, because there will be a lot of small SW companies trying to implement a QMS before March 21st 2010...

[JaneB]

Micked,

I think it depends n whether the bug reports you're talking about are part of the normal process of developing software, or whether they're something that turns up after the product has been released/delivered.

The former don't require CA or PA - assuming you're using an iterative development process etc. The latter do.

In Reply to Parent Post by Micked

If I deal with a pure SW product it is a bit different, at least to my simplistic mind.
"Returns" are usually bug reports in this case. To me it seems a bit over the top to analyze bugs for:
- Specification errors (preventive action is better training in writing specifications?)
- Coding errors (Corrective action is to fix the bug? Do I have to make a CAPA investigation for this? Preventive action is training in coding rules?)

Disagree. If you have delivered /sold software to a customer which you subsequently discover had errors in it, you absolutely need to figure out why and how those errors were in there, to prevent recurrence. And yes, if that means better spec writing or having some coding standards/rules, yes. WHy on earth not? What makes IT so 'special' that it shouldn't have to do this, whether you have 1 programmer or 50?

In Reply to Parent Post by Micked

I think this is a question of general relevance, because there will be a lot of small SW companies trying to implement a QMS before March 21st 2010...

Why before then?

[Hodgepodge]

In Reply to Parent Post by Micked

If I deal with a pure SW product it is a bit different, at least to my simplistic mind.

I don't see how it is different. The purpose of a CAPA program is to fix a problem and prevent its recurrence. A software company would want to do this the same as a hardware manufacturing company. The end result is customer satisfaction. An added benefit is the potential savings in time on future projects (and time equals money).

In Reply to Parent Post by Micked

- Specification errors (preventive action is better training in writing specifications?)
- Coding errors (Corrective action is to fix the bug? Do I have to make a CAPA investigation for this? Preventive action is training in coding rules?)

It depends. Preventive action is a planning activity and can be used as input for training requirements. Corrective action should definitely fix the problem, but it can be much more. Though not every corrective action must be formally documented, if a company keeps having to fix the same problem, it hasn't addressed the root cause. This could lead to better training, safeguards, etc. I agree with Jane B. Every company can benefit from a good CAPA program and good training/instruction.

In Reply to Parent Post by Micked

And, in my case where there is one (!) programmer in the company, what is reasonable to do there?

That is why I want to create one simple to use and simple to understand system for everything from internal bug reports to customer complaints.

I think your idea of keeping it simple is a great idea. If your customer actually uses this simple system AND they can find ways to improve, then it is a successful system. The smaller the operation, the more everyone has to do to make a successful CAPA program work. Perhaps instead of just participating in a meeting or discussion to determine root cause, those involved may have to enter data into the system or fill out paperwork themselves, keeping them from their normal, hopefully productive, duties. A simple program is imperative. It sounds like you are on the right track.

[Micked]

JaneB and Hodgepodge,

Thanks for your feedback.
Nothing beats a little provocation to get the discussion going

First a note on March 21st 2010. That's when the new European Medical Device Directive 2007/47/EG will apply. It now specifically defines standalone software products as medical devices, if they are used for diagnostic purposes. This has been a gray area so far. Just think about all the patient management and imaging systems out there...

I don't think programmers are exempt from quality activities, even if my first post sounded like it. My problem is to get the client do the minimum required activities, and make it consistently, instead of just being overwhelmed with a cumbersome process.

I guess most people in this forum have a background from mid-size to large corporations. Mine is from Siemens Medical, one of the largest electromedical manufacturers in the world. It was no problem to have two full-time engineers handle customer complaints at my workplace, as an example. This is simply not realistic for most small companies. That's why I am being a bit provocative to get a feeling for the minimum acceptable level.

How about two checkboxes: "Needs corrective action" and "Needs preventive action" in the issue handling tool?
The SOP would then prescribe the actions and follow-ups needed if checked.

I have so far described the process such that all actions and follow-ups shall be entered as comments in the tool. If a requirement has to be changed or added, then it should be referenced in the tool. Together with reference to verification, of course. If done this way, there should be a very small need to make printouts and sign them with ink. Currently I recommend to make printouts at opening a customer complaint, when a decision not to investigate is made and at closure of the complaint.
Any comments to this "hybrid approach" to electronic signatures?

[jkuil]

I recently made a CAPA procedure for a mid-sized medical device company. I recognize the requirements for a simple CAPA system. We have managed this through the handling of 'simple' NCs at engineering level.

If at any time in the life cycle non-conforming SW is detected, the software should be corrected. Subsequently, the need for corrective actions (CAPA) is analysed. If the issue is simple, i.e. is straightforward and the corrective actions (if required) are obvious, actions can be determined, approved and implemented at engineering level. There is no requirement for detailed root cause analysis or risk analysis.
If the issue is complex or potentially a high risk for the software users is involved, the non-conformance handling requires approval at management level. These issues are thoroughly investigated: detailed root cause and risks analysis, in order to ensure effective corrective actions.

Non-conformances are trended and the trend analysis is reviewed by top management. Through this review (simple) NCs repeating at too high frequency are detected and the need for corrective actions is determined.

[Micked]

That sounds like a good approach. I will simply put in a checkpoint in the issue handling process, "CAPA needed?".