Got SOUP? - Part 1 - Because every good software starts with SOUP
By Mitch on Friday, 17 May 2013, 14:21 - Standards - Permalink
No need to reinvent the wheel when developing software. Everybody uses software made by 3rd parties, to begin with the operating system and general purpose libraries.
IEC 62304 has specific requirements about 3rd party software. What are these requirements and how do they affect software development and maintenance?
According to IEC 62304 terminology, 3rd party software are Software of Unknown Provenance, aka SOUP.
What is a SOUP, what is a not SOUP?
Not every 3rd party software is a SOUP. Software developed and maintained with respect to IEC 62304 requirements or with respect to medical devices regulations are not SOUP.
Simple case
If 3rd party software is designed and maintained with respect to IEC 62304, and you have contractually access to the documentation, then this software is not a SOUP. This is the simplest case. It basically happens when the 3rd party is a sub-contractor or a software library manufacturer, with ISO 13485 certification or a QMS compliant to other regulation (eg 21CFR in the US), completed with IEC 62304 compliant processes.
This is the gold standard, but it is not always feasible.
Other simple case
At the opposite side, if software comes from an open-source repository, from a private research lab (even in your company), from a university, or from any other 3rd party that has no process complying with IEC 62304, then this is a SOUP.
The source may be the most truthful one in terms of quality of software or technological advance, it doesn't matter. If this 3rd party hasn't a QMS with IEC 62304 compliant processes, its software is a SOUP according to IEC 62304.
This is usually the case of the immense majority of 3rd party software.
Borderline cases
But in most of cases the situation isn't so simple. Here are some examples.
If the software is a legacy software developed before your company implemented IEC 62304, see the series on legacy software.
If the software comes from a 3rd party which is IEC 62304 but you don't have access to the software documentation, then try to change the contractual conditions (easy to say...) or treat it as a SOUP, or not, if you have a good justification to do so.
As a matter of fact, 3rd party software can be qualified as SOUP on a case-by-case basis. It mainly depends on the type of relationship with the software manufacturer and the nature of the documentation delivered with the software.
Examples of SOUP
Here are some examples of SOUP:
Operating Systems
Almost all OS's are SOUP: Windows, MacOS, iOS, Android, Linux and so on...
To my best knowledge, no OS is claimed being designed for medical purposes by their manufacturers (I heard that QNX was, but I haven't seen satisfying documentation yet).
Hardware Drivers
All drivers delivered by hardware manufacturers are SOUP. Unless this hardware is a medical device or an accessory of medical device, designed and maintained with respect to standards and regulations.
Software Development Frameworks
High level frameworks like J2EE, ASP.NET, Flash, Ruby on Rails are not SOUPs. Lower level frameworks delivered by microchips manufacturers are not SOUP either.
They are used in IDE at design time and never delivered to the end-user.
Runtimes
Contrary to frameworks, all runtimes used to make software work are SOUP: C runtime, ADA runtime, Java runtime, Common Language Runtime, runtimes delivered by micro-controllers vendors, any runtime language interpreter...
Open-source libraries
Whichever the license, open-source libraries are SOUP. The licensing terms found in open-source licenses like Apache or LGPL neither help nor make more difficult the use of 3rd party software in medical devices.
IMHO, Open-source is another debate.
One could argue that access to source-code is a help to SOUP management. Perhaps yes, in peculiar cases.
IDEs, compilers
Development tools are not SOUP, compilers either. They are used in factory, not in clinical settings. They shall be validated by IQ, OQ and PQ.
Just-in-time compilers can be categorized as SOUP as they run with software delivered in clinical settings.
Where are we?
This makes a lot of SOUP!
You may think this IEC 62304 standard is a real burden, that you have far more to do than you thought!
Well, not so much, IEC 62304 is not a basket case! We'll see in next articles how to deal with these SOUPS.
Comments
A setup I sometime face at our customers is that they let a sub-contractor that do not use IEC62304 develop parts of the embedded system (I've only experienced this for class A/B SW). In some cases, the sub-contractor provides source code and documentation, in other cases it's only a binary library. The software typically runs on a separate piece of hardware.
If IEC62304 is read strictly this isn't SOUP as it's neither generally available nor developed for any other purpose than to be used in one or several of the customer's products. I.e. it doesn't fit into: "SOFTWARE ITEM that is already developed and generally available and that has not been developed for the purpose of being incorporated into the MEDICAL DEVICE (also known as “off-the-shelf software”) or software previously developed for which adequate records of the development PROCESSES are not available"
My general approach is to always try and get hold of the source code. This isn't only due to regulatory issues but also in order to "own" the software and be able to update it during verification/validation/maintenance. The customer then "learns" the software and handles it as if they developed it them self.
It would be interesting to hear your thoughts. Would you handle this as SOUP if you had/hadn't access to the source?
Hi Martin,
Tanks for your comment!
Software developed by a sub-contractor for the sole purpose of being used in the manufacturer's medical devices is not SOUP.
The problem is more in the contract with the subcontractor. The manufacturer shall add requirements in the contract to make sure that the subcontractor delivers something helping the manufacturer to meet IEC 62304 requirements. Source code and sw development documentation are necessary.
When it's not possible to have the source code, it's better to change of subcontractor! When the subcontractor is the only one to be able to develop a given software, we are in the situation you describe. In this case, we are more or less in the second part of the SOUP definition:
software previously developed for which adequate records of the development PROCESSES are not available
Thus, considering such software as a SOUP is a possibility. But this is the last solution. It's better to change of subcontractor if they don't want to deliver the source code!
Hey Mitch- If a medical device happens to have openoffice installed on it, but it is not being used or called by the software, is it SOUP?
Thanks,
Avraham
Hi Avraham,
No, not a SOUP hence not used for the intended use of your software. Maybe a line could be added in the risk assessment on possible disturbances made by open office. But that's belt and shoulders.
So If the soup is small, say a JS open source control. If you take that code through the QMS process, e.g. code review, integration testing etc is that now not considered soup? It seems that who coded it matters less than if it is fully processed by the QMS.