From SOUP to Nutz – Software of Unknown Provenance
How I Learned to Stop Worrying and Love Software of Unknown Provenance
Because Software of Unknown Provenance, or SOUP, has a variety of definitions or explanations, depending upon the source, we’ve laid out this information in a SOUP FAQ Format for easier understanding.
Here are the most frequently asked questions about our favorite SOUP – Software of Unknown Provenance!
What is SOUP and where does it apply?
When it comes to developing medical devices, SOUP is what’s called Software of Unknown Provenance. SOUP includes third Party Libraries, and whatever software you’re using in your medical device engineering that you didn’t code yourself.
Which specific regulations explain all the SOUP requirements?
IEC 62304 has two definitions of SOUP:
- Software not developed for a medical device
- Software with unavailable or inadequate records
There are two types of SOUP. There is Clear SOUP which is where the Vendor supplies source code and fault history but can be lacking development under a compliant QMS. And then there is your basic SOUP where little to no development artifacts are available.
What are SOUP risk levels and how do they apply?
IEC 62304 requires you to assess risks associated with SOUP the simplest way is to classify each SOUP as a certain risk level.
- Low – Malfunction in SOUP can’t lead to patient harm
- Medium – Malfunction in SOUP can lead to reversible patient harm
- High – Malfunction in SOUP can lead to irreversible patient harm
IEC 62304 Risk is governed by ISO 14971.
Does my medical device class matter when it comes to SOUP?
Your medical device class does indeed matter when it comes to software of unknown provenance.
For Class A, you only need to document very little (you have to identify SOUP, such as dependency files).
When you have Class B and C medical device software, where there is any risk of injury, then you should be looking closely at your SOUP.
- Specify functional and performance requirements of each SOUP item
- Specify system hardware and software of each SOUP item
- Evaluate published SOUP anomaly lists
When is SOUP addressed during Medical Device software development?
This is performed during the SDLC Implementation Phase, prior to design and prior to implementation. During this phase you need to update the architecture diagram and update the SOUP list.
What is a SOUP List?
You really do need to create an actual SOUP list that includes all of your software of unknown provenance. For each third-party library you use, for example, add an entry in the table. The idea is to only have one global SOUP list for your medical device, even though the code may actually have multiple repositories. That’s what the ‘software system’ column is for; you could also mention your (git) repository there.
When specifying requirements, the 62304 requires you to mention functional, performance, hard- and software requirements. However, you may not have to re-state certain requirements if they apply to all SOUP, e.g. “runs on Linux”. So, prefer to keep the requirements simple, in a way in which you would communicate it to colleagues on your development team when answering the question “why did we import this library?”.
As with all templates: It’s more about the content (i.e., the columns you see below) than the tool (filling this out in Google sheets / markdown / wherever). Nobody says that you have to maintain this as a Google sheet. If you can find a way to integrate this in your workflow in a better way, e.g. in a markdown file in your git repository, go for it! Just keep in mind that you need to be able to export it to send it to auditors.
|Pkg Name||Programming Language||Version||Website Link||Last Verified||Risk Level||Requirements||Verification|
Now that you know a little more about Software of Unknown Provenance you can rest easy knowing you’ve got it under control!
In our next SOUP Blog, we are going to discuss the following aspects of Software of Unknown Provenance:
- What are the relevant requirements of SOUP item
- What is the intended use of SOUP, including the performance requirements imposed by
- What hardware and software is necessary to support the proper operation of the SOUP items
- What is used to verify the software architecture was implemented correctly, and that SOUP items operate as intended
- For SOUP configuration items, what information should be included in the list?
- What activities are performed against the functional safety requirements?
Still confused about dealing with SOUP? Contact the Advantu medical device experts today.