SOUP: FDA’s Recipe for Open Source Software 

Q: Is it acceptable by FDA to use open source software for low critical applications? These applications do not have a direct impact on patient safety but are used to support GxP activities. An example would be a software testing tool.

If the answer is yes, what controls should we consider during our validation activities? I look forward to hearing the thoughts and responses directly from the FDA experts.

A: Yes, it’s acceptable to use open source software — and it has always been acceptable for medical applications, tools in production, and other manufacturing and quality purposes. It’s also acceptable to incorporate open source software into finished products as long as you comply with the regulations.

Validation is required, regardless of origin (open source or not) for all software used in regulated activities.

21 CFR Part 820.70(i) requires that software used for production or quality purposes must be validated, which means the software must be documented as having been created using good software development practices. So validation is required, regardless of origin (open source or not) for all software used in regulated activities.

FDA and industry have provided some guidance for using SOUP (Software Of Unknown Pedigree or Provenance). Two FDA guidances — which don’t use the SOUP acronym but still apply — are FDA’s Off-the-Shelf Software Use in Medical Devices and of course FDA’s General Principles of Software Validation. For additional information, I suggest you search on something like “using SOUP for regulated activities”. You’ll find there’s a lot out there.

As for validation controls, they must be based on the risk of the software used. You have to perform a risk analysis of the code used and its functions in your system. So your controls could range from decomposing the software and documenting it thoroughly to performing automated code review and testing.

An unfortunate example of a failure in the past was government-developed software (SOUP, even though from the government this time) that was used for imaging without adequate control. In this case, the open source software caused or at least contributed to reversed X-ray images (and eventually to recalls).

So, especially in applying open source software, be very careful and thoroughly understand (and document) your intended uses and your risks.

Answered by Martin Browning, President and Co-Founder of EduQuest, who served 22 years at the U.S. FDA as an expert field investigator and who also co-wrote 21 CFR Part 11. His education and background are in computer engineering. Martin is the chairman of EduQuest’s FDA Auditing of Computer Systems and Part 11/Annex 11 Compliance training class.


Leave a Reply

Your email address will not be published. Required fields are marked *