55 lines
3.7 KiB
Markdown
55 lines
3.7 KiB
Markdown
# SOUP List (Software of Unknown Provenance)
|
|
|
|
> 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`.
|
|
|
|
| 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 |
|
|
|
|
## 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 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. |
|
|
|
|
## 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.
|
|
|
|
| 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](https://facebook.github.io/react-native/) | 23.10.2020 | Low | * Runs JS on Android / iOS | Commonly used, maintained by a large organisation, sufficient test coverage |
|
|
|
|
---
|
|
|
|
Template Copyright [openregulatory.com](https://openregulatory.com). See [template
|
|
license](https://openregulatory.com/template-license).
|
|
|
|
Please don't remove this notice even if you've modified contents of this template.
|