Medical device manufacturers must have a documented Corrective Action and Preventive Actions procedure. This procedure provides the authoritative definition the CAPA subsystem of the company’s overall quality system. The CAPA procedure may reference additional procedures that further define it.
For manufacturers in the United States, when FDA audits your CAPA procedure they will:
- Verify that CAPA system procedure(s) that address the requirements of the quality system regulation have been defined and documented.
- Determine if appropriate sources of product and quality problems have been identified. Confirm that data from these sources are analyzed to identify existing product and quality problems that may require corrective action.
- Determine if sources of product and quality information that may show unfavorable trends have been identified. Confirm that data from these sources are analyzed to identify potential product and quality problems that may require preventive action.
- Challenge the quality data information system. Verify that the data received by the CAPA system are complete, accurate and timely.
- Verify that appropriate statistical methods are employed (where necessary) to detect recurring quality problems. Determine if results of analyses are compared across different data sources to identify and develop the extent of product and quality problems.
- Determine if failure investigation procedures are followed. Determine if the degree to which a quality problem or nonconforming product is investigated is commensurate with the significance and risk of the nonconformity. Determine if failure investigations are conducted to determine root cause (where possible). Verify that there is control for preventing distribution of nonconforming product.
- Determine if appropriate actions have been taken for significant product and quality problems identified from data sources.
- Determine if corrective and preventive actions were effective and verified or validated prior to implementation. Confirm that corrective and preventive actions do not adversely affect the finished device.
- Verify that corrective and preventive actions for product and quality problems were implemented and documented.
- Determine if information regarding nonconforming product and quality problems and corrective and preventive actions has been properly disseminated, including dissemination for management review.
More information on how the FDA will inspect your CAPA process is available from the FDA.
Additional information on FDA inspection protocol is available here.
No time to chat!
I won’t do this often, but I wanted to share a picture from a current client engagement. In this case, the work involves improving a software release process.
For this particular client, we have taken them from approximately two releases per year to one release every six weeks. We have not even begun to approach the limit as to what can be done. The release process will change significantly as we continue to reduce cycle time while improving software quality. Sounds paradoxical, but absolutely true.
Ask yourself what benefits can be obtained when you can release software 2x or 3x more quickly than your competitors, while improving the quality of the released software at the same time.
There is an elephant in the room for many development shops that are using C++ in the development of safety-critical systems.
The elephant is this: C++ is an extremely complex programming language.
Let me first work to support this claim. In other words, is there evidence that C++ is an extremely complex programming language?
Rob Pike, a distinguished engineer from Google, has written this article.
In a talk he gave in 2010 at the O’Reilly Open Source Conference, Pike made his case against such “industrial programming languages” during his keynote at the conference. Quoting from that keynote:
“I think these languages are too hard to use, too subtle, too intricate. They’re far too verbose and their subtlety, intricacy and verbosity seem to be increasing over time,” Pike said. “They’re oversold, and used far too broadly.”
There are times when C++ can be too verbose, but that’s not the most serious problem. In my experience, the most serious problem is the difficulty journey-level engineers have in using the language safely and confidently. It is an extremely subtle and intricate language; it’s easy to do fail to understand some corner-case, with the result being a surprising error at run-time, or, more often, a great deal of time is wasted by people who are both very expensive and somewhat unclear on exactly what their C++ code actually means.
If you work with C++ developers, you may be able to verify this yourself. Get a few of them together in a group and ask them to explain the pros and cons of C++ move semantics, which were introduced in C++11. As they discuss the topic, see if you can determine whether they are speaking confidently, and whether everything is obvious to them, or whether they are perhaps somewhat less than confident in their grasp of the subject matter.
I don’t wish to beat a dead horse, but there is also this thread by Linus Torvalds to be considered. Linus Torvalds is the primary author for the Linux operating system. It’s an incredibly successful open source operating system that is used, well, everywhere, today.
C++ is not one language, but several, if you consider the significant revisions that have occurred over the years. There is an ISO standard for the language – International Standard ISO/IEC 14882:2012(E) – Programming Language C++. You can purchase a copy of the standard for about $60.00, but you will be in for a lot of reading. The standard is a well-written but complex technical document. It is not light reading and runs to 1,356 pages in length.
The last points I will make are these. First, there is a whole industry devoted to building tools to help C++ programmers find subtle errors in their code. Second, my own experience of 20 years of developing code in C++ has taught me that most people in any development shop are not language lawyers. They learn the language well enough to get along, and to fit in to the tribe, but they never learn the language well enough to be able to avoid being periodically surprised by some aspect of it. I understand why this happens – there is going to be variation in every group – but it’s a problem when your developers aren’t in full intellectual control of the language they are using to write the code that is going to be running on the medical device you intend to ship.
At this point, it might seem as if I am against the use of C++ for the development of safety-critical, embedded systems. I am not. C++ can be used, safely and well, in such contexts. But it’s not a triviality and it doesn’t happen without a concerted and continued effort to realize it.
If you are going to use C++ in the development of such systems, you must have a full, conscious, objective and shared understanding of exactly what you are signing up for. There are many, many things you can do to ensure that your C++ development proceeds at an effective rate, while at the same time ensuring that the product you develop is safe and effective (or, in more modern parlance, meets its essential performance requirements.)
As just one example of what can be done, let me suggest the following.
In any development group of more than a few individuals, you are almost certain to have one or two people who could serve as the language lawyers for the group. Allow them to participate in setting the standards for code development in your group. Then verify that what they advocate is actually good practice – perhaps invite some outside experts to review your code base and SOPs. The language lawyers should be working from one or more of the well-known books from individuals like Herb Sutter, Scott Meyers and other recognized experts. Believe me, these people earn tens of thousands of dollars every time they address a group of developers. Your language lawyers should be reusing their carefully-considered and vetted recommendations.
Once you have adopted and established standards for good practice within your development group, you’ll be much less likely to get into trouble. That being said, the development of safety-critical embedded systems in C++ will likely never be easy.
Additional Information:
- Derek W. Reinhardt, Masters Thesis, “Use of the C++ Programming Language in Safety Critical Systems”
- JOINT STRIKE FIGHTER AIR VEHICLE C++ CODING STANDARDS FOR THE SYSTEM DEVELOPMENT AND DEMONSTRATION PROGRAM
- Prof. Christian Madritsch, “C++ for Safety Critical Systems“
It is common to think that regulatory requirements like IEC 62304 are burdensome and a “necessary evil.” Perhaps it depends on your mindset, but I see them as a significant opportunity for any business that is truly committed to a real process of ongoing improvement.
Let me cite a case in point.
Today, I was writing a software requirements specification for a client. The specification applied to the software licensing subsystem in their product software. This is subsystem that determines what capabilities of their product have been licensed by a given customer, and hence, whether that customer may use those capabilities.
I produced my first draft of the SRS and emailed it within the client’s organization, asking for redlines. Standard operating procedure in engineering organizations.
A little later in the day, one of the client’s engineers and I sat down to discuss his comments. As we did, and after about thirty minutes, I recognized that we could make a very significant simplification in the how the subsystem would work. It really was a thing of beauty, and we both recognized it as such.
The simplification was such that it allowed for the licensing subsystem to be independent of the business logic that the client would implement as part of their sales process. In other words, the client’s Sales function would be free to design whatever licensing rules they wanted, and the licensing subsystem in the product would be able to implement it without any changes.
The take-away is that following the IEC 62304 standard caused us to invest more time up-front in requirements analysis. That, in turn, led to the discovery of a major simplification in how the licensing subsystem will work. And that simplification will ensure that the licensing subsystem will not have to be revised then next time the client decides to change the business rules associated with product feature licensing.
Finally, this simplification also means that we will be able to auto-generate some of the test cases necessary to show that the licensing subsystem has been carefully verified.
IEC 62304 – whether it’s a blessing or a curse is entirely up to you!
I have been an advocate for the Theory of Constraints since 1992, when I was introduced to it by a colleague, Doug Fullaway. At the time, Doug was the Vice-President of Sales for Applied Microsystems, and had just returned from a trip to Japan.
Apparently, he had been given a copy of Eli Goldratt’s book, “The Goal,” while in Japan.
“The Goal” is something of a gateway drug for people who ultimately go on to become advocates for the Theory of Constraints. I remember that I read the book in a weekend, and was hooked from that point on. Many people thought the book was just an interesting business story, but to me, it was too convincing to be just a novel. There had to be more to it.
Over the years, I have come to appreciate how deep Eli’s insights actually go. Eli was a man who passionately embraced reason and evidence.
If you want to improve your business – or any system, really – I highly recommend the Theory of Constraints body of knowledge. If it makes some sense to you, give me a call and let’s chat about it in more depth. There really are no limits on how much any system can be improved.
John at 55!
“How do you know?”
It’s a question I frequently ask myself – and it’s a question that often comes to mind when I’m listening to other people.
For example, one of my clients once claimed that the device his company manufactured did not need to carry the CE Marking. Knowing the nature of the device and the nature of many of the Directives that drive the requirements for CE Marking, this seemed hard to believe.
So I gently asked “How do you know?”
His reply was that one of the other members of his firm had found an exemption. To their understanding, because their device was intended for use in research laboratories, they thought that a particular exemption for medical devices would also be applicable to their device.
Of course, this is not true. An exemption granted by one Directive, such as the Medical Device Directive, does not create a blanket exemption from all other Directives, such as the Low-Voltage Directive, or the EMC Directive.
This problem – of knowing how we know something – is the subject of epistemology. Epistemology is the investigation, or study, of what distinguishes justified belief from opinion.
I have found epistemology to be a fascinating subject. And when I think of how many decisions I make on a day to day basis, and how many of those decisions might be on the basis of unsubstantiated or unchecked assumptions, it’s a bit concerning!
My personal strategy, and the strategy we use at Common Sense when working with our customers, is to always work from a basis of reason and evidence. Over the years, I have found that this is the only practical means for ensuring that we are delivering real value to all of our stakeholders. And in fact, in my view, it’s the only way one can really live.
In closing, I want to thank you for reading this post. I hope you’ll consider sharing your thoughts with me.