SOUP is not scary

De blogs op onze website worden in het Engels geschreven en niet apart vertaald. Vandaar dat onderstaande in het Engels is.

SOUP or Software Of Unknown Providence is software that is used in a medical device but was not developed to be used in a Medical device (or with all the documentation to prove it was) [1]. While in some cases the use of SOUP is not desirable, in most applications the use of SOUP for some functionality is perfectly acceptable and often the preferred option. A lot of the time SOUP can be documented within a couple of days depending on what it is and how it is used. An important thing to keep in mind here is that compliance is not the same as quality:
“…one device manufacturer can meet FDA requirements and still make a poor quality device whereas a second manufacturer may not comply with all FDA requirements and yet make a high-quality device”
Jeff Shuren, M.D., J.D., Director CDRH [4]

Note: While SOUP may also denote other kinds of software, in this article it only applies to commercial off the shelf software and to some extend free open source software. The types of software it applies to cover a very broad range and can include among others: libraries, device drivers, reporting software, databases and communication software.

I’ve seen developers jump through all kinds of hoops to keep SOUP out of their device thinking that the amount of work needed to document the use is insurmountable. I even saw code from a developer that had “desouped” some device drivers by basically copying code and renaming the functions (that’s not how this works! It is how plagiarism works tough…).

There are two big advantages of using SOUP over newly build software. The first is the most obvious: the economic advantage. Building software costs time and money so if you can buy a piece of software that is used by other people and thus share the costs it will save you money. But as the industry has moved from risk control based on ALARP (As Low As Reasonably Practicable) to AFAP (As Far As Possible) the economic advantage alone might not be enough to decide in favor of SOUP.

The second, and in my opinion most crucial advantage of SOUP, is that in a lot of cases it has been used and thus tested in ways and numbers that are impossible to cover yourself before releasing your medical device to a larger audience. This of course only goes for software that is actually used by other people, which is not always the case, especially for some of the more obscure open source projects. While the safety of the product should of course always be guaranteed by rigorous safety checks, bugs and annoyances still happen in medical software and often only surface when a product has been used for a while or in ways that nobody expected. If you can use the experiences of someone else for some parts of your software, you can prevent bugs and annoyances in your product. While this may not be something you can use as evidence, it does imply some form of quality. The fact that people are using it in itself already implies that it provides some functionality. Besides that, if people are using the software it will be easy to find out what kind of issues there are and if they are happy with what it does. In this case you can get actual experiences from users and fellow developers from social media, forums and reviews. This goes a long way in finding out the quality of the SOUP. Another thing to keep in mind is that with feature rich software, the features you intend to use may not be the features other people are using. So before committing to using specific software as SOUP, it is important to find out how much it is used and how it is being used.

The process of recording the use of SOUP varies. The key factor here is the risks the SOUP covers and poses to the medical device and patient and how well it can be separated from the rest of the software. SOUP that provides a core functionality of your medical device or that is used as part of a risk control measure, is very hard to bring under control without extensive support from the supplier. In these cases, you will have your work cut out for you to prove it is safe to use and you may need to consider if it is the appropriate choice.

But in most cases the SOUP is of little concern as it usually provides functionality at the fringes of the system and risks are already controlled by controls in other parts of the software and in the hardware. In these cases, it is enough to document: what it is, what it needs, what it does and how it is managed [2]. This is often done in the software architecture. Besides the documentation specific to SOUP, the features it provides to your system should be covered in the normal tests, requirements and other applicable documentation just like all other software [3].

For devices for which the software is classified as class C in the IEC 62304 standard, it may be necessary to segregate the SOUP from the software items that are classified as class C, just like this is needed for class A and B items. How this segregation is done will vary wildly with different SOUP and platforms. But the goal here is to prove that unexpected behavior from the SOUP will not pose risks to the class C software items. Segregation may come in different forms ranging from a simple wrapper to different processes to physically separate processors.

So, to sum up, medical device manufacturers do not need to be afraid of SOUP and it can and should be used in medical devices, if there is no suitable alternative that was developed according to medical standards. But before chosing to use something that is SOUP, it is recommended to take into account how much it is used and for what purpose.

Sources used:

[1] IEC 62304 – medical device software – software life cycle processes

[2] FDA guidance for off-the-shelf software http://www.fda.gov/downloads/MedicalDevices/.../ucm073779.pdf

[3] Frequently Asked Questions related to the Implementation of EN 62304:2006 with respect to MDD 93/42/EEC
http://www.team-nb.org//wp-content/uploads/2015/05/documents2013/FAQ_62304_Final_130804.pdf

[4] CDRH Center Director Discusses Case for Quality
https://www.youtube.com/watch?v=X4KAOCi1RuE