When we talk about SOUP in medical devices, we’re not talking about a bowl of chicken noodle goodness. SOUP stands for Software of Unknown Provenance and is formally defined within IEC 62304 (Medical device software – Software life cycle processes), but it’s generally understood as ‘off the shelf’ software items which are used in a medical device.
There are two parts to the definition of SOUP:
1. A software item which was not developed for direct use in a medical device: For the most part, this will be any library, driver, or file, which your device development team did not directly create. In my opinion, this is the intended purpose of permitting SOUP within medical devices.
2. An item which does not have appropriate evidence of the development process: This could be some software which you produced, prior to design control being in place. Don’t be tempted into thinking that you can list your entire software sub-system as a SOUP item: BS EN 62304 Appendix 1 specifically states that this cannot be done.
It’s important to understand why each of the stages of SOUP evaluation (and use) are required for IEC 62304 compliance. To summarise, you need to:
The major benefit of SOUP in medical devices is in the improved product development times: there is no need to re-invent the wheel. This is particularly true when using complex software components whereby the significant design time and specific technical experience may not be available within the development team.
Common examples of the benefits of SOUP in medical device software include:
• Hardware drivers – chip manufacturers often provide interface libraries which simplify and standardise the initialisation of the processor, similar to USB and SD, drivers
• Middleware – more complex items such as a file system, or graphical framework
• Operating systems – support more complex software architectures
However, these benefits don’t come for free. With this in mind, let’s explore the whole process of selecting, documenting, integrating and evaluating Software of Unknown Provenance in medical devices.
Before you can identify or integrate your SOUP item, you have to select one! The item needs to meet the specified requirements, but there are some key points which can aid selection:
Once you have selected the SOUP item, you need to document it thoroughly. This documentation is vital to help you maintain your software, and will include:
BS EN 62304 gives specific requirement types which should be considered when documenting SOUP items:
1. Performance requirements: The characteristics which must be met, in order to use the SOUP item (response times, for example).
2. Functional requirements: What functionality must the SOUP item provide? Does it have to be compatible with a particular language?
3. System and hardware requirements: If your SOUP item requires a particular processor, or a minimum amount of memory in order to function then this needs to be documented. Alternatively, you may select your SOUP item in order to operate on your existing platform!
As with all requirements’ definitions, the key is that they should be testable. This allows you to identify whether or not the SOUP item is doing what you need it to.
As developers, this is the fun bit! Your software design and architecture will need to incorporate your Software of Unknown Provenance items. In the case of the library items, this can be quite simple: you design your software to incorporate the needs of the SOUP item, checking for errors, ensuring the appropriate memory is available, etc.
For more complex SOUP items, this integration can affect the overall software architecture. Take an RTOS as an example, you will need to ensure that your architecture allows for sufficient memory and adequate configuration of peripherals for the RTOS to be initialised.
A SOUP item can be fundamental to your overall software design. Your architecture will need to support use of the SOUP item, and you will need to incorporate any of the risk mitigations which you have previously identified.
Depending on the Software of Unknown Provenance item in question, you can have a variety of verification methods. However, it’s crucial that you record how you verify that the requirements were met, and the status of the verification activity.
The verification that the SOUP item meets your requirements should be performed before you start to integrate the design, following selection. Similarly, if there are any updates to the SOUP item, verify against these requirements before the update is integrated!
You also need to verify that your software architecture supports the use of the SOUP item, this can occur after development and integration.
When using Software of Unknown Provenance in medical devices, you need to ensure that it is fit for purpose by defining both the functional and performance requirements of the SOUP item and then verify that it meets these requirements. Throughout this process, as with all medical software development, we are performing continuous risk management.
SOUP evaluation doesn’t end when the source code has been released
Software of Unknown Provenance evaluation doesn’t end when the source code has been released, as developers will periodically produce updates to SOUP items; some of these may resolve issues which impact your device software. Post market surveillance is a key part of using SOUP.
Why does this matter? The cases mentioned earlier are easy to spot. They may involve additional purchases, or the developers may have to store the library within the codebase. Less obvious is the code provided by the compiler! To be compliant within ISO13485:2016, your compiler must be a validated tool, however as part of your software lifecycle, one needs to be aware that it also contributes to SOUP items! In real terms: you can’t avoid having SOUP in your product altogether.
To someone coming across this for the first time, BS EN:62304 may make the process seem complex, however, this needn’t be the case.
If the SOUP item can cause a performance failure, odd result, or any other risk to the patient / user, then this needs to be considered and mitigated against. Most commonly, you’ll put this in your software risk analysis documentation, but it may be useful to identify any risks prior to selecting the SOUP item. This is because the Software of Unknown Provenance provider may offer mitigations directly if they have also identified the problem.
Your risk identification may generate further requirements of your SOUP item, or may specify a design requirement to integrate the item safely.
Releasing a product is never the final stage of developing medical software: it’s crucial that the performance of the software in the field is known. Are there any reported failures or bugs? Have there been any changes in the environment which need to be accounted for?
This is also true for any Software of Unknown Provenance which has been used: if the manufacturer releases a new version of the SOUP item, it’s important to evaluate what has changed and if any changes impact your product. It’s possible that the change in SOUP item has no impact on your software, by producing new features which will not be used. However, it’s also possible that the changes may resolve bugs which had not been identified at the time of release.
The documentation you produced when identifying the SOUP item will help here, as it enables you to trace the versions which you are using, and identify the changes. Furthermore, keeping track of changes in your SOUP items allows you to plan ahead – you can modify your software to account for identified risks before they cause a problem, or you can be prepared to integrate the new SOUP item when it becomes available.
Remember that, over time, the development team will change, so make sure you keep your plans up to date as this happens. Get into the routine of checking for changes in SOUP items before the release of your device/software, as this will allow you to keep the momentum as the product moves forward.
Looking for industry insights? Click below to get our opinions and thoughts into the world of medical devices and healthcare.
