What is SOUP? – How to Handle Software of Unknown Provenance
Today’s theme is “SOUP.” It is certainly a unique concept with a distinctive name. However, the SOUP concept is positioned as critically important in today’s software development field. Let us explain what makes it specifically important in a way that even beginners can understand.
Definition and Characteristics of SOUP
First, let us discuss what SOUP is. SOUP stands for Software Of Unknown Provenance, referring to software whose development history is unclear. This includes software developed in the past, commercially available software, and open-source software, where the development process is not distinctly evident. In IEC 62304 (Medical Device Software Lifecycle Processes), SOUP is defined as “an off-the-shelf software product or software component with known functionality,” making it a particularly important concept in medical device development.
Because the development and design process of such software is unclear, special attention is required when utilizing it. Specifically, when software behaves in unexpected ways, it becomes difficult to pursue the root cause. Additionally, adding new functions or modifying existing functions may become problematic. Furthermore, if security vulnerabilities exist, understanding their scope becomes challenging, and this can directly impact the risk profile of the entire medical device.
Position in Medical Device Regulations
SOUP is subject to specific management requirements when incorporated into medical devices. Importantly, it is necessary to understand that a medical device cannot practically be composed entirely of SOUP alone. Rather, a typical configuration combines software developed by the medical device manufacturer (referred to as “active software”) with SOUP components.
In IEC 62304 (7th edition) and related FDA guidance (such as “Software as a Medical Device (SaMD): Clinical Evaluation”), the responsibility falls on the developer to demonstrate that the safety and effectiveness of SOUP do not compromise the risk profile of the overall medical device. This means developers must verify that failures originating from SOUP do not adversely affect the safety and effectiveness of the final medical device.
Under the EU MDR (Medical Device Regulation), Article 51 requires that the technical documentation specify the types, functions, and versions of off-the-shelf software used, and describe how these are considered in the risk management process. This requirement ensures transparency and traceability in regulatory compliance.
Proper Management of SOUP
To properly handle SOUP, several important measures are necessary. First, when using SOUP, it is essential to clearly define its scope of application and ensure its use remains within that scope. This means thoroughly reviewing the functional specifications of the SOUP and verifying alignment with the medical device’s functional requirements.
Second, it is necessary to continuously collect information from vendors regarding known defects, security updates, and support end dates for the SOUP. Particularly from a cybersecurity perspective, in order to comply with IEC 81001-5-1 (Cybersecurity for Medical Network Devices) and the FDA’s “Cybersecurity Guidance for Medical Device Manufacturers,” periodic security assessments of SOUP are critical. This proactive approach helps prevent security-related failures in post-market medical devices.
Third, periodic testing and verification must be performed, and modifications and improvements made based on the results. Medical device developers must conduct integration testing that verifies the SOUP performs as intended when integrated into the medical device system. This verification goes beyond simple functional testing and must include comprehensive testing covering safety-critical scenarios and edge cases.
Version management of SOUP is also important. After a medical device is marketed, if security updates for SOUP become available, the manufacturer must decide whether to apply them. When applying updates, re-verification and impact assessment are expectations of regulatory authorities. This process ensures that SOUP updates do not introduce unintended consequences or new risks into the medical device.
SOUP and Business Continuity
Most importantly, when using SOUP, it is essential to keep firmly in mind that the development history is unknown. Each software carries the intentions and purposes of its developers embedded within it. Understanding and respecting these aspects form the foundation for properly utilizing SOUP.
Furthermore, in modern practice, the business continuity of SOUP vendors has become an important consideration factor. If a vendor ceases operations, security updates may no longer be provided. Facing such scenarios, medical device developers must conduct risk assessment in advance and, if necessary, consider transitioning to alternative software. This is particularly important for medical devices with long lifecycle periods.
In conclusion, while SOUP brings efficiency and economic benefits to medical device development, its management carries commensurate responsibility and attention requirements. Through understanding regulatory requirements, continuous risk assessment, and comprehensive verification processes, the proper utilization of SOUP leads to the realization of high-quality medical device development.
