Best Practices for SOUP artifacts and reports
What is SOUP?
“…Software of Unknown Provenance (SOUP Software): SOFTWARE COMPONENT that is already developed and widely available, and that has not been developed, to be integrated into the MEDICAL DEVICE (also known as "Off-The-Shelf Software"), or previously developed software for which adequate records of the development process are not available…” [2]
Any piece of code that was not developed by a Medtronic employee and was used in the product or application or as part of the build process could be considered SOUP. This includes open source and other 3rd party libraries, frameworks such as .NET, mobile OS SDKs, and DevOps tools such as Octopus Deploy and Azure Artifacts are part of this list so that we can ensure that we do not miss anything.
Each of the items that could be SOUP, as described in the previous paragraphs is then assessed based on the flowchart below. Note that a person can manually do this entire process including adding the information to a Word doc and uploading to MAP Agile.
Regulatory Requirements for SOUP: ANSI AAMI IEC 62304:2006/A1:2016
US regulatory requirements for SOUP have been adopted from the International Electrotechnical Commission (IEC). In practice, the requirement means that any SOUP has to undergo validation according to already existing Medtronic processes that depend on the level of risk to the patient
“…IEC 62304 defines three safety classes for software:
-
Class A: No injury or damage to health is possible
-
Class B: Non-SERIOUS INJURY is possible
-
Class C: Death or SERIOUS INJURY is possible
| Software documentation | Class A | Class B | Class C |
|---|---|---|---|
| Software development planning | X | X | X |
| Software requirements analysis | X | X | X |
| Software architectural design | X | X | |
| Software detailed design | X | ||
| Software unit implementation | X | X | X |
| Software unit verification | X | X | |
| Software integration and integration testing | X | X | |
| Software system testing | X | X | X |
| Software release | X | X | X |
X = Required
What Is the Current State at Medtronic
Once discovered, SOUP can be handled using Medtronic’s existing processes of software validation and verification to satisfy national and international regulatory bodies’ requirements. There are several things to consider: 1. DOC000689 Rev U – Design Controls: Top Level Procedure 2. DOC000660 Rev 1E – Design Controls: Software Unknown Provenance (Soup) Evaluation 3. 10079765DOC Rev K – Design Controls: Design and Development Planning 4. FRM001243 Rev 1M – Design Plan Addendum 5. 10139638DOC Rev 1F – Purchased Software Validation
NOTE: Most teams today manually create and maintain this list and expect to do so in AZDO until automated solutions become available.
-
Build operations automatically list software, among that list are SOUP’s, though this is not a complete list.
-
There are processes of Validation and Verification in place to handle SOUP.
-
Validation and Verification documentation resides in Medtronic repositories for access by internal and external auditors
-
Git app version management
Automating SOUP Identification
We have developed a proof of concept .NET application that shows how to use a dependency tracker in an Azure Pipeline. Check out this file for a guide to enabling a dependency tracker in a pipeline.
This sample project shows how to add the tags in a .NET application. A similar approach could be used in a Java application using Maven.
Once you have set up the dependency tracker and created the tags you can consume this data from Cosmos DB and/or using Power BI as described here.