3 MIN READ
Using SOUP in medical devices
Unfortunately, we’re not talking about a bowl of chicken noodle goodness. Software Of Unknown Provenance (SOUP), is formally defined within IEC 62304 (Medical device software – Software life cycle processes), but generally understood as ‘off the shelf’ software items which are used in a medical device (we will discuss the formal definition in a future blog).
The major benefit of SOUP is in the improved product development times: there is no need to re-invent the wheel. This is particularly true when using complex software components whereby the significant design time and specific technical experience may not be available within the development team.
Common examples of the benefits of SOUP include:
• Hardware drivers – chip manufacturers often provide interface libraries which simplify and standardise the initialisation of the processor, similar to USB and SD, drivers
• Middleware – more complex items such as a file system, or graphical framework
• Operating systems – support more complex software architectures.
However, these benefits don’t come for free.
When using SOUP, you need to ensure that it is fit for purpose by defining both the functional and performance requirements of the SOUP item and then verify that it meets these requirements. Throughout this process, as with all medical software development, we are performing continuous risk management.
SOUP evaluation doesn’t end when the source code has been released
SOUP evaluation doesn’t end when the source code has been released, as developers will periodically produce updates to SOUP items; some of these may resolve issues which impact your device software. Post market surveillance is a key part of using SOUP.
Why does this matter? The cases mentioned earlier are easy to spot. They may involve additional purchases, or the developers may have to store the library within the codebase. Less obvious is the code provided by the compiler! To be compliant within ISO13485:2016, your compiler must be a validated tool, however as part of your software lifecycle, one needs to be aware that it also contributes to SOUP items! In real terms: you can’t avoid having SOUP in your product altogether.
To someone coming across this for the first time, BS EN:62304 may make the process seem complex, however, this needn’t be the case.
Through a series of blogs we will examine:
• The regulations, in particular the requirements of BS EN:62304
• How to evaluate SOUP
• Some practical experience in using SOUP
• Post market surveillance of SOUP.