Got SOUP? - Part 6 - FDA Guidance and Conclusion
This is today the last article of this series about SOUP.
SOUP is a concept that we find elsewhere than in the IEC 62304 standard. Namely in the FDA guidances.
FDA guidance on SOUP
The FDA uses the same concept as the SOUP concept found in IEC 62304, and uses the term Off-The-Shelf Software.
There is one guidance about off-the-shelf-software, the Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices.
You can find the link to download it in the Essential list of guidances for software medical devices.
This guidance introduces the need of documenting the COTS hazard analysis differently, according to its level of concern. The level of concern defined by the FDA, is roughly equivalent to the safety class defined by the IEC 62304.
Following the decision tree found in this guidance can help defining the documentation that is needed for the risks analysis. This is complementary to what is required by IEC 62304.
A good technical file may contain risk analysis documentation with both approaches.
BTW, we found also in this guidance section 2.3 about hazard mitigation, that matches pretty well the ISO 14971 requirements.
FDA guidance about 21CFR part 11
To go further about COTS, we can have a look at what exists for software that are not medical devices.
An issue about which much was written is the electronic signature of documents, and their legal origin: the 21CFR part 11. There are a few guidances about this subject, still in draft state.
One guidance: the Guidance for Industry 21 CFR Part 11; Electronic Records; Electronic Signatures Validation, has a section about Commercial, Off-The-Shelf Software (COTS). Even if it is in draft state, it's worth reading section 6.1, especially for standalone software.
However, this guidance has been in draft state for years, and is outside the field of medical devices. Read it only to have additional information about software validation.
We've seen that SOUP is a big family. It can be considered as an all-embracing concept with very different cases.
That's why we tried in this series of articles to split them in sub-categories, with tips of implementation for each of them.
Theoretically, there are lots of tasks to do to be sure that SOUPS are well integrated, work in appropriate conditions, without unacceptable risks. In practice, all these tasks have to be completed with scrutiny for class C software only, down to the detailed design of software units.
For class B software, depending on the type of SOUP quoted above and the type of medical device, a macroscopic risk assessment of the SOUP may be enough, limited to the interaction of SOUPs with the software medical device. However, a deeper risk assessment may necessary, if the functions delivered by the SOUP bring risks with a high severity.
For class C software, all activities are mandatory. The best solution is to limit the number of SOUPs used by the software, to avoid overloaded SOUP management.