How to document SOUP for IEC 62304 compliance?

Accepted answer
You need to create a list of your dependencies. That list can be a spreadsheet, a markdown file, or pretty much anything else which you can save as do
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, 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).
Unsure how to get started and how to get your EU MDR medical device certified?
We've already helped 100+ companies with their MDR compliance.
Take a look at our services and book a free 30-minute consulting call.
Accepted answer
You need to create a list of your dependencies. That list can be a spreadsheet, a markdown file, or pretty much anything else which you can save as do
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
orGemfile
.
Classes | IEC 62304:2006 Section | Document Section |
---|---|---|
B, C | 5.3.3 (Functional and Performance Requirements) | 2 |
B, C | 5.3.4 (Hardware and Software Requirements) | 2 |
B, C | 7.1.2 (Hazardous Situations) | 2 |
B, C | 7.1.3 (SOUP Anomaly Lists) | 2 |
A, B, C | 8.1.2 (Identify SOUP) | 2 |
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 Level | Definition |
---|---|
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. |
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.
ID | Software System | Package Name | Programming Language | Version | Website | Last verified at | Risk Level | Requirements | Verification Reasoning |
---|---|---|---|---|---|---|---|---|---|
1 | Mobile App | react-native | JavaScript | 0.61 | Link | 23.10.2020 | Low | * Runs JS on Android / iOS | Commonly 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.