Design
SOUP List
Document third-party software components with risk assessments ensuring safe integration and regulatory compliance.
Summary
The Software of Unknown Provenance (SOUP) List documents all third-party software components, libraries, and off-the-shelf software used in your medical device. This document provides risk assessments, version control, and requirements for each SOUP item to ensure safe integration and regulatory compliance.Why is SOUP List important?
SOUP components represent potential points of failure in your medical device that are outside your direct control. Regulatory authorities require comprehensive documentation of all third-party software because these components can introduce unknown risks to patient safety. The SOUP list demonstrates that you have systematically identified, assessed, and controlled risks associated with external software dependencies. Without proper SOUP documentation, you cannot demonstrate that your device is safe or that you understand all potential failure modes. The SOUP list also enables ongoing monitoring for security vulnerabilities and updates that might affect your device’s safety and effectiveness throughout its lifecycle.Regulatory Context
Under 21 CFR Part 820.30 (Design Controls) and IEC 62304:2006:
- All SOUP must be identified and documented with risk assessments
- Functional and performance requirements must be specified for medium/high-risk SOUP
- Must demonstrate systematic evaluation of SOUP risks
- Version control and change management required for all SOUP
Special attention required for:
- Cybersecurity vulnerabilities in SOUP components
- FDA Software as Medical Device guidance compliance
- Software Bill of Materials (SBOM) requirements
- Ongoing monitoring and update procedures for SOUP
Guide
Understanding SOUP
Software of Unknown Provenance (SOUP) is any software that your team did not create or that wasn’t created specifically for your medical device but is nonetheless part of your medical device. SOUP includes:- Third-party libraries and frameworks (React, NumPy, TensorFlow)
- Off-the-shelf software (operating systems, databases, authentication services)
- Cloud services that are integral to your device’s medical functionality
- Open source components and commercial software packages
SOUP vs Non-SOUP Determination
Not all third-party software is SOUP. Software is only considered SOUP if it is used as part of your medical device to achieve the intended medical purpose. For example: SOUP Examples:- Authentication service that controls access to patient data
- Machine learning library used for medical diagnosis
- Database storing critical patient information
- Communication protocol for medical device connectivity
- Marketing website hosting service
- Development tools not included in the final product
- Administrative software for billing or scheduling
- Non-medical notification systems
SOUP Risk Classification
Classify each SOUP component based on potential patient impact: Low Risk: SOUP malfunction is unlikely to lead to patient or user harm- Example: UI styling libraries, non-critical logging components
- Example: Data validation libraries, communication protocols
- Example: Medical calculation algorithms, critical data storage systems
Documentation Requirements
For all SOUP items, document:- SOUP ID: Unique identifier for tracking
- Software Item: Which part of your architecture uses this SOUP
- Name and Version: Exact version numbers (must be pinned, not auto-updating)
- Manufacturer/Source: Who developed or maintains the SOUP
- Description: What the SOUP does in your system
- Risk Level: Low, medium, or high based on patient impact
- License: Legal terms governing SOUP use
- Functional Requirements: What the SOUP must do for your device to function
- Performance Requirements: Speed, accuracy, or capacity requirements
- System Requirements: Hardware and software needed to support the SOUP
Version Control and Monitoring
Pin all SOUP versions to prevent automatic updates that could introduce unknown risks. Establish monitoring procedures:- High-risk SOUP: Review every 6 months for vulnerabilities and updates
- Medium-risk SOUP: Review annually
- Low-risk SOUP: Review every 2 years
Example
Scenario: You’re developing a diabetes management app that processes glucose readings, provides insulin dosing recommendations, and stores patient data. You need to identify and assess all SOUP components used in your system.SOUP List
| SOUP ID | Software Item | SOUP Name | Version | Manufacturer | Description | Risk Level | License | Requirements |
|---|---|---|---|---|---|---|---|---|
| SOUP-001 | Mobile App | React Native | 0.72.4 | Meta | Cross-platform mobile app framework | Low | MIT | UI rendering and navigation functionality |
| SOUP-002 | Backend | Express.js | 4.18.2 | OpenJS Foundation | Web application framework | Medium | MIT | HTTP request handling, API routing, requires Node.js runtime |
| SOUP-003 | Backend | bcrypt | 5.1.0 | Kelvin Sherlock | Password hashing library | High | Apache-2.0 | Secure password hashing for user authentication, must provide cryptographic security equivalent to 256-bit encryption |
| SOUP-004 | Database | PostgreSQL | 15.3 | PostgreSQL Global Development Group | Relational database system | High | PostgreSQL License | Patient data storage with ACID compliance, backup and recovery capabilities, encryption at rest |
| SOUP-005 | Backend | jsonwebtoken | 9.0.2 | Auth0 | JWT token implementation | High | MIT | Secure user session management, token expiration handling, cryptographic signature validation |
| SOUP-006 | Mobile App | React Navigation | 6.1.7 | React Navigation Contributors | Navigation library for React Native | Low | MIT | Screen navigation and routing functionality |
| SOUP-007 | Backend | Helmet.js | 7.0.0 | Adam Baldwin | Security middleware for Express | Medium | MIT | HTTP security headers, XSS protection, requires Express.js compatibility |
Risk Assessment Summary
High-Risk SOUP (3 items): These components handle critical security functions (authentication, data storage) and medical calculations. Failure could lead to data breaches or incorrect medical recommendations. Medium-Risk SOUP (2 items): These components handle data processing and security but have lower direct patient impact. Failure could disrupt service but is unlikely to cause direct patient harm. Low-Risk SOUP (2 items): These components handle user interface functions. Failure would affect usability but not patient safety or data security.Q&A
How do I create a comprehensive SOUP list?
How do I create a comprehensive SOUP list?
A SOUP list requires a complete inventory of all third-party dependencies, documenting versions and licenses. Start with your package manager files (package.json, requirements.txt, etc.) to identify dependencies. Include off-the-shelf software and cloud services that are integral to your medical device functionality. Perform a risk assessment for each component based on potential patient impact if the SOUP fails.
How should third-party software integration be approached?
How should third-party software integration be approached?
Third-party software can be integrated as a medical device system module, listed as a supplier, and added to architecture documentation. Create specific subsystem requirements for third-party components and maintain your current device classification. Document all third-party software in your SOUP list with appropriate risk assessments.
What's the difference between SOUP and Off-The-Shelf software?
What's the difference between SOUP and Off-The-Shelf software?
SOUP (Software of Unknown Provenance) is any third-party software used in your medical device, while Off-The-Shelf (OTS) software refers to commercially available software packages. OTS becomes SOUP when it’s used as part of your medical device to achieve the intended medical purpose. Not all OTS is SOUP - only the components that contribute to medical functionality.
How do I handle SOUP version updates?
How do I handle SOUP version updates?
All SOUP versions must be pinned to prevent automatic updates. When updates are needed, treat them as design changes requiring impact assessment, testing, and documentation updates. Evaluate security patches promptly but implement them through your change control process. High-risk SOUP updates require more extensive verification than low-risk updates.
What level of detail should I include for SOUP components?
What level of detail should I include for SOUP components?
Document all SOUP components with their name, version, source, and functional purpose. Include risk classification based on potential impact if the SOUP fails. For medium and high-risk SOUP, specify functional and performance requirements, system dependencies, and verification approaches. Maintain the SOUP list as a living document updated with each software release.
How do I monitor SOUP for security vulnerabilities?
How do I monitor SOUP for security vulnerabilities?
Establish ongoing monitoring procedures based on risk level. Subscribe to security advisories from SOUP manufacturers, monitor vulnerability databases (CVE, NVD), and use automated scanning tools where appropriate. High-risk SOUP requires quarterly review, medium-risk annual review, and low-risk biannual review. Document all vulnerability assessments and remediation actions.