T-012-032 SOUP Name
Description
Provide a general description of the SOUP. Include its purpose, provider, key features, and any compatibility notes. Mention whether it is open source or proprietary, and its general use case.
General details
Fill in key metadata for the SOUP:
- Developer or provider
- Whether it's open source
- Supported programming languages
- Repository (if available)
- License type
- Operating system compatibility
- Maintenance status (is it actively maintained?) Use bullet points for clarity.
Intended use on the device
Describe the specific use of the SOUP within the medical device. Mention how and where it is integrated (e.g., for data storage, communication, authentication, etc.). Be specific and aligned with the device’s architecture.
Requirements
Functional
List the functional requirements the SOUP must fulfill (e.g., compatibility, scalability, security, backup). Describe what the software must be able to do to support its use in the device.
Performance
Specify expected performance characteristics: availability, durability, throughput, latency, etc. Focus on measurable criteria that affect system reliability and responsiveness.
System requirements
Software
Indicate any necessary software dependencies or configurations required for the SOUP to function. If none, state that clearly.
Hardware
Indicate any specific hardware requirements. If the SOUP runs on standard environments without special hardware, state that explicitly.
Documentation
Include a link to the official documentation. Then, provide a checklist or criteria to validate that the documentation is adequate:
- Is it clear and comprehensive?
- Is it regularly updated?
- Does it cover all the features used in your device?
Related software items
Map the version(s) of the SOUP to specific software items or microservices that use it. Use a table format: | SOUP version | Software item(s) | If each microservice uses its own isolated instance (e.g., Docker), clarify that.
Related risks
List the risks related to using this SOUP, referencing your official risk management document. Use bullet points or numbers and ensure each risk is clearly described (e.g., maintenance, vulnerabilities, incompatibility).
Lists of published anomalies
Provide links to the SOUP's official changelogs, release notes, or incident tracking systems to monitor bugs, patches, or anomalies.
History of evaluation of SOUP anomalies
List past evaluations of the SOUP for known issues. For each entry include:
- Date of review
- Name of the reviewer
- Versions evaluated
- Summary of findings (e.g., no anomalies found) Repeat for each date/version as needed.
Record signature meaning
Define the roles and identifiers of the people involved:
- Author (person who wrote the record)
- Reviewer (person who verified the content)
- Approver (person who approved it for formal inclusion)