So, when you start out on your exciting (yes) regulatory journey, pretty early on you’re going to come across the word “CAPA”. Seasoned regulatory professionals and consultants will casually throw it around, like “just open a CAPA for that” and they’ll feel pretty smart, while you’ll feel pretty dumb.
But worry not and look no further, today we’ll explain it, and just like all regulatory concepts, this one is so easy to understand that even your dog could become a regulatory consultant! The difficulty, as always, lies in the fact that information is scarcely available and fiercely guarded by consultants who charge exorbitant rates for explaining stuff to you.
Let’s get started!
What Is a CAPA (Corrective and Preventive Action)?
CAPA stands for Corrective and Preventive Action and, as you might have guessed, describes actions your company takes which are corrective or preventive in nature.
The requirements for CAPAs are defined in the ISO 13485 which is the standard for quality management for medical devices. While I could cite the relevant sections there and bore you to death, I’ll skip that part and show you a CAPA example which will help you understand it much better.
CAPA Example
CAPAs are a bit like todos in a project management system, or issues in GitHub, or tickets in Jira. The content however focuses on things which went wrong in your company, why they went wrong, and how you will improve them.
Let’s look at the example first before we explain some of the content further below.
CAPA Example: The Actual Example
Description: One of the software developers decided to ship an update of the medical device software to production (let’s assume it’s a web application) without going through the usual process, i.e. without the proper documentation, approvals, testing, etc. - whatever you defined in your software development SOP (you have one, right?).
Related Document / Process: SOP Software Development.
Root Cause Analysis: The software developer didn’t know about the right process, and it was technically possible to publish a software update without the proper approvals.
Actions: The proper documentation will be created for the update retrospectively and it will be tested etc. If it is deemed unsafe during this process, it will be rolled back. Additionally, better safeguards for pushing software to production and better employee training will be implemented.
Potentially Adverse Implications: None.
Deadline: Creation of proper documentation and potential rollback of the update immediately, better safeguards and employee training before the next product update.
Verification: Documentation created, employee training performed, technical safeguards implemented.
Validation: Next update was shipped according to process.
CAPA Example: Explanation
Okay, so there’s a lot going on here, but in the end it’s just a (rather boring) description and analysis of something which went wrong. In this case, your medical device consists of software and a software developer just pushed a new update to production.
While agile coaches worldwide would celebrate this as great success (“we ship every day!”), regulatory authorities of medical devices generally see this as a problem, because for each change it is expected that you create a ton of documentation. Besides whether this is good or bad (and that’s a whole separate rant-worthy discussion), the problem here is that it’s not compliant with your company’s processes and the regulatory requirements.
Aha! So from that we can already learn something: Typical triggers for creating CAPAs are when something happens which is not compliant with your own processes (your SOP documents) or with the regulatory requirements, or both.
Okay, the next step, as we can see in the example above, seems to be to do some sort of root cause analysis. There are different methods for this - personally, I like the Five Whys method because it’s quite simple (and was invented at Toyota by the way - you’re welcome, I’m happy to provide this random fact to you for some distraction). To apply it, you just ask why? five times and note down the answer. And of course you don’t provide the same answer each time, duh, but the next why? always refers to the last answer. Here’s what I mean:
Five Whys: Why was the plane forced to perform an emergency landing?
- Why? Because it no longer could fly at its desired altitude.
- Why? Because the engines stopped running.
- Why? Because they ran out of fuel.
- Why? Because the pilots ordered an insufficient amount of fuel at the last airport.
- Why? Because there was an error in the fuel calculation when converting between metric and imperial units.
The above example actually describes the Gimli Glider, an incident which happened for real and is definitely worth a read if you’re as interested in aviation as I am, and as disinterested in CAPAs as I am. It’s quite a feat that the pilots managed to land that airplane with both engines shut down.
Okay, back to CAPAs.. sigh. Next, you define some actions you need to take. Not much to explain here. Obviously, those actions should mitigate and possibly even prevent whatever went wrong. You also need to note down any potentially adverse implications of your actions. You wouldn’t want to make things worse, right?
Moving forward, you need to set a deadline until when these actions shall be implemented. If you start thinking that this is all terribly overengineered, I’m with you. Regarding the deadline, it can either be a fixed date in the future, or some abstract event, like the release of your next medical device version.
And finally, there’s the verification. Quality people (those people who are often detached from reality because they only care about “quality”, but have no clue how to develop real products, not unlike the hygiene people in hospitals) love to lecture you on verification and its difference to validation, but let’s not go there today and cut it short: Verification is showing that you actually did it, while validation should show that it actually achieved its goal.
In the above example, our verification is that we actually implemented our actions (duh), and the validation is that those actions actually had the desired effect, in this case that the next software update was shipped in a compliant way (and probably took forever to get done because the overhead became enormous, thank you very much, quality people).
Now you probably have a very obvious question: How the hell do you fill all of this out in one go? Commonly you wouldn’t have done your verification and validation when you’re just defining the CAPA, right? Yep, totally right! That’s why you generally don’t fill out CAPAs in one go.
You’d create one, enter the title and description, and come back later to do the root cause analysis. And then later you’d define some actions, and again later update it when you’ve verified those, etc.
And that’s it “already”. Now you know how medical device companies are able to employ large teams of regulatory people, yet get nothing done. This sort of procedures might make sense in large companies, and especially in hardware companies, but in software companies their usefulness sometimes seems as questionable as the turned-off metal detectors in the subways in the developing country I’m currently working from (not Berlin, by the way).
And that’s it about the CAPA content! Now let’s discuss how to manage CAPAs in an efficient way so that you don’t go crazy at your (presumably) small medical software startup.
Software Tools for CAPA Management
After consulting with 100+ companies, what are the typical software tools I’ve seen for managing CAPAs? Ranked by popularity, those would be:
- A terrible, document-based solution, e.g. in Word, Google Docs, or markdown documents in GitHub / GitLab
- Spreadsheets (Google Sheets or Excel)
- Jira or a similarly crappy ticket system
- Somethines fancy, either an eQMS or a self-made solution in Notion or so.
Let’s look at those in order.
CAPA Management: The Terrible, Document-Based Solution
If you’re a person who likes structure like I do, how would you organize your CAPAs? Looking at the example above, a reasonable person might think “hm, for each CAPA I have to fill out the same fields, so let’s create a spreadsheet”. Right? This would lead to a CAPA spreadsheet which is a reasonable solution.
But, for some reason which I yet have to understand, I see document-based solutions instead. Like, people would create a new document for each CAPA - literally a new Google Doc for each new CAPA, and in that, you’d have the headings “description”, “root cause analysis”, “actions”, etc.
Crazy, right? A surefire way to create a big mess. Because now you no longer have the ability to get an overview over your CAPAs - which one is lacking a root cause analysis? No clue! We need to literally open all of those damn CAPA documents to have a look!
So please don’t do this. If your consultant provides you with a CAPA template which assumes that each CAPA should be a new document, your best way forward should be to fire your consultant.
Next up, spreadsheets!
CAPA Management: Spreadsheets (Google Sheets, Excel)
Now you might think that I’d similarly dislike spreadsheets. That’s actually not true! Spreadsheets can be a surprisingly good and flexible solution for managing table-based data - like for your CAPAs. As a matter of fact, our own CAPA List Template (completely free, no strings attached!) is based on a table-like structure and we recommend you to import it into Google Sheets (or Excel, if you must).
So spreadsheets for CAPA management generally work - cool. They have some drawbacks, though. The biggest problems I usually see are:
- Too little structure: While spreadsheets give you some structure, they often don’t give you enough structure. When people don’t have a lot of regulatory experience but are tasked with managing CAPA spreadsheets, they often might lack guidance on how to fill them out properly.
- Notifications: You can define your CAPA deadlines in a spreadsheet, but it won’t magically notify you when the deadline is approaching, unfortunately.
- Automation and calculating KPIs: Regarding CAPAs, there are quite a few tasks which could be automated in a really cool way - for example you could automatically calculate the duration it took to “close” a CAPA, and automatically import that into your management review. Spreadsheets won’t be able to do that, you’ll need a more fancy solution for that.
But before talking about fancy solutions, let’s talk about Jira and similarly crappy solutions.
CAPA Management: Jira Or a Similarly Crappy Ticket System
I’ve also seen companies set up their CAPA management in Jira. This is truly the worst of both worlds: Jira is less flexible than a spreadsheet (it’s harder to change “columns”, or rather, fields), yet it doesn’t provide any useful automation - like, does it notiy you when the deadline approaches? Does it automatically calculate KPIs for you? Nope.
In addition to that, exporting your data from Jira is much harder. The typical options are badly-formatted Word or PDF documents. Ugh. Compare that to a spreadsheet: Even though a spreadsheet is not a perfect solution, you can export it in a way which looks good.
CAPA Management: eQMS Or Other Fancy Software
And finally, you could use eQMS software (that’s specialized regulatory software) to manage your CAPAs. The benefits of those are pretty much the inverse of the spreadsheet drawbacks:
- Intuitive to use and structured: A good eQMS software guides users through creating CAPAs, making it obvious how to fill out each field.
- Notifications: Notify users when deadlines are approaching.
- Automation: Calculate KPIs (e.g. durations between certain CAPA steps) and provide those to the user for easy inclusion in the management review report. Cool!
- Digital signing: If your eQMS software supports digital signing, you can even sign CAPAs directly there, too - no need to export them into some crappy, third-party signing tool to show that you’ve finished handling the CAPA.
Ah, and this whole eQMS discussion would not be complete without me mentioning our own eQMS software called Formwork, of course - it has all the benefits mentioned above, but above that, I think its main benefit is that it’s super intuitive to use. It guides even regulatory newbies through the process of creating (and understanding) CAPAs in a compliant manner. And in addition to that, there’s a free version and our pricing is not evil like all our enterprise competitors! Okay, end of self-promotion.
CAPA Hacks
Before we wrap up, a quick “CAPA Hack”! If you’re about to face an audit by a notified body or state authority and have some obvious deficiencies in your documentation, just open a CAPA for those - that way, they can’t give you serious findings in that area any more because you’re already handling it. I thought this was pretty cool. Like throwing pencils at bureaucrats.
Anyway, that’s it! Have fun managing your CAPAs, use our free CAPA template and, if you’re in the mood for some cool automation, check out Formwork!