How can you employ the medical device CAPA best practices in your bug tracking?

How can you apply some of the best practices of a medical device in your non-regulated product? And does it worth the efforts?

In this post, I will describe just a small tweak in your bug form, that will make a huge difference in your bug management and the quality of your product, with just a small tweak of adding “Root Cause” field to your bug form. 


It will make your team THINK. Check it out

What is CAPA

A CAPA stands for  Corrective And Preventive Actions. To make it short – when something bad happens – you are supposed to do some investigation, understand the root cause of what happened, when, why, and come up with a plan of what you need to do in order to fix (Corrective) and to prevent it in the future (Preventive).

Adding Root Cause

Well, there is plenty you can do. But as I said, in this article, I would only discuss a small tweak: Add “Root Cause” field to you bug form


Because it will force your team to THINK. That’s it, no more. And when they think – this is when you start digging gold

Orcanos use case

I will explain using a true use case of Orcanos


Root cause starts with an investigation


We got a timeout message for our dynamic filter. It happened to one of our customers, so you can imagine, it didn’t look too good…as we had to deliver a quick fix.

A bug was reported and fixed, but the root cause field, which is mandatory inOrcanos, said something like “Problem in the query”. So we started an investigation to dig the REAL root cause.


The developer says “It was due to a wrong query to the database”, we ask: WHY? Why did it happen? “Well, It happened because we fixed the filtering mechanism, and the original query didn’t fit”. Oh really? Tell me more. “We have changed the filtering mechanism but didn’t change it in all the places we use this filtering mechanism, such as the dynamic filter”


Because…well, this is a sensitive area, and I was under pressure to deliver and didn’t have the time to go to all places and fix it. It would require lots of testing, and put us in high risk…”
So…Are there more places to check?

“Well…yes…but it only happens when the response has thousands of records…”

So, it will continue to happen, and if I understand correctly, we might have an issue in more places

“..we need to check…”

The decision was NOT GOOD since the problem was not fully resolved

But – the decision was GOOD in terms of reducing risk in a frozen environment and affecting more customers, as this rarely happened


So what could you do better?

“Well, I could fix the bug for immediate resolution, and raise another bug, or task for an overall fix in the next release, I guess…”


It goes and on for more corrective and preventive actions, changing our working instructions, and emphasis these topics on our weekly meetings. 

All because of one investigation. 

So you see, It’s more of a state of mind than a technical stuff


See that sometimes the root cause can reveal much more than just a code mistake. It teaches you about how your team thinks, and what drives them in their decision making, sometimes without seeing the big picture. 

These investigations make them and you to think in a wider scope and become EXCELLENT!