Template: SOUP List (Software of Unknown Provenance)

Dr. Oliver Eidel
Updated May 18, 2024

Template Download

This is a free template, provided by OpenRegulatory.

If you are a user of Formwork, our eQMS software, you can save a lot of time by choosing “QMS” on the top menu and “OpenRegulatory Templates” on the left menu, and then opening the relevant folder to find this template ready to load into Formwork.

If, for some mysterious reason, you’re using a different QMS Software, you can also simply download this template – specifically, as Word (.docx), PDF, Google Docs or Markdown file. Scroll down for a preview!

The template license applies (don’t remove the copyright at the bottom, don’t re-use this for commercial purposes).

Talk To A Human?

We also offer consulting if you need a more hands-on approach. We’ve helped 150+ Healthcare companies. Take a look!

Template preview

The 62304 requires you to document your SOUP, which is short for Software of Unknown Provenance. In human language, those are the third-party libraries you’re using in your code, typically in your requirements.txt or Gemfile.

ClassesIEC 62304:2006 SectionDocument Section
B, C5.3.3 (Functional and Performance Requirements)2
B, C5.3.4 (Hardware and Software Requirements)2
B, C7.1.2 (Hazardous Situations)2
B, C7.1.3 (SOUP Anomaly Lists)2
A, B, C8.1.2 (Identify SOUP)2

1 Risk Level Definitions

The 62304 requires you to assess risks associated with SOUP. The simplest way to do this is to classify each SOUP as a certain risk level. Unless you’re developing software which shoots radiation at patients, it’s likely that your SOUP risk levels remain “low” or “medium”.

Risk LevelDefinition
LowMalfunction in SOUP can’t lead to patient harm.
MediumMalfunction in SOUP can lead to reversible patient harm.
HighMalfunction in SOUP can lead to irreversible patient harm.

2 SOUP List

This is the actual SOUP list. For each third-party library you use, add an entry in the table below. The idea is to only have one “global” SOUP list for your medical device even though the code may actually live in 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 them 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.

IDSoftware SystemPackage NameProgramming LanguageVersionWebsiteLast verified atRisk LevelRequirementsVerification Reasoning
1Mobile Appreact-nativeJavaScript0.61Link23.10.2020Low* Runs JS on Android / iOSCommonly used, maintained by a large organisation, sufficient test coverage

Template Copyright openregulatory.com. See template license.

Please don’t remove this notice even if you’ve modified contents of this template.

Template preview


Leave the first comment