Team Consulting writes:
In the first part of this series, we gave a brief overview of what Software Of Unknown Provenance (SOUP) is, and hinted at its importance within the medical software lifecycle.
This piece will look at the steps we need to take to evaluate SOUP in establishing compliance with BS EN 62304: Medical device software. Software life-cycle processes. Like all good recipes, SOUP evaluation has a list of key items (ingredients), steps, and processes which, if followed, will give you the outcome you’re after. Missing any one of the steps can lead to issues further down the development line.
There are two parts of the definition of SOUP:
– 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.
– 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.
Knowing what SOUP is helps us to understand why each of the stages of SOUP evaluation (and use) are required for 62304 compliance. In summary you need to:
– Document the requirements of the SOUP item
– Assess the risks posed by a type of SOUP item
– Select, identify, and record, the SOUP item being used
– Design your software architecture to include the SOUP item
– Verify that your SOUP item meets your requirement
– Monitor your SOUP item
Document SOUP requirements
When producing any software as part of a medical device, it’s important that we document the requirements; the specific things that the software must be or do. These requirements are used to provide the inputs to design and development teams and to verify the software. This is no different for SOUP, although BS EN 62304 gives specific requirement types which should be considered for SOUP items.
– Performance requirements: The characteristics which must be met, in order to use the SOUP item (response times for example).
– Functional requirements: What functionality must the SOUP item provide? Does it have to be compatible with a particular language?
– 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’ definition, the key is that they should be testable. This allows you identify whether or not the SOUP item is doing what you need it to.
Risk Analysis and Identification
It’s one of the key aspects of all medical device development. What could go wrong here? Can we detect it? How do we handle it?
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 SOUP 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.
Select, Identify, Record
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:
– Does it have any safety certification?
– Is the item still supported?
– How widely is it used?
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:
– The SOUP title
– The manufacturer of the SOUP item
– A unique designator – (version number, serial number, or similar)
Design and Integration
As developers, this is the fun bit! Your software design and architecture will need to incorporate your SOUP 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.
Verification
Depending on the SOUP 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.
Maintenance
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 SOUP 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, by 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, 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, this will allow you to keep the momentum as the product moves forward.
//Banner vector created by katemangostar
//People vector created by pch.vector