Subscribe to our Blog

Medical Device Development 101

Reducing the Uncertainty of SOUP

We know that medical device development projects often face financial or other constraints that make it necessary to include so-called “off the shelf” or third-party software into an otherwise high-integrity system.

Reducing the Uncertainty of SOUP

You'll get a great recipe for handling software of unknown provenance (SOUP) in your Medical Device.

But we also know that this is easier said than done. When you decide to include such third-party software into your medical device, you then have to deal with:

  • there are no guarantees that such software will reliably perform the necessary safety-related functions, and
  • it may prevent other software, hardware or firmware from performing their safety-related functions.

So, can you really benefit from this kind of existing third-party software without compromising your system? We have good news: yes, you can! Read on to find out what we’ve learned about including such software into many projects.

What is SOUP?

Software of unknown provenance (SOUP) describes software that has been included in medical devices or in medical software (including software as a medical device) that was not developed according to a known software development process or methodology, or which has unknown or no safety-related properties.

The standard IEC 62304:2006 (Medical device software – software life cycle processes) specifically defines SOUP as:

Software 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.

IEC 62304:2006 does not prohibit the use of SOUP but additional controls are required and the risk of the SOUP needs to be assessed and taken into account.


Benefits of SOUP

The major benefit of SOUP is in the faster product development times. Essentially, with SOUP, you don’t have to re-invent the wheel. This is particularly true when using complex software components which themselves require significant time and specific technical expertise which may not be available within the development team, e.g. operating systems.


SOUP or not SOUP?

Not all third party software is SOUP. Software developed and maintained with respect to IEC 62304 requirements or with respect to medical device regulations are not SOUP.

Then, what is SOUP?

Well, any software that was NOT developed following IEC 62304 compliant processes is SOUP.


SOUP can be software from an open-source repository, from a university, from your own company or from any other third party. Some common examples of software that is SOUP are:

  • Operating Systems
    • There are no operating systems that have been specifically developed for medical devices, so all OSs are SOUP.
  • Hardware Drivers
    • In general, all hardware drivers are SOUP. The exception would be if the hardware is a medical device or an accessory of a medical device and has been designed and maintained with respect to the relevant standards and regulations.
  • Runtimes
    • Since runtimes are used at runtime, they are definitely SOUP because they are used in the end-user operation.
    • While most compilers are not SOUP, just-in-time compilers, can be considered as SOUP because they run with the software delivered to the end-user.
  • Open-source libraries
    • Whichever the open-source license, open-source libraries are SOUP.
  • Code developed in your company before design control was in place
    • In this case, even though the code may have been developed by the same team working on your medical device, the code was not developed according to the prescribed development process compliant with IEC 62304, and so would be considered SOUP.

There are also some clear examples of software that is not SOUP:

  • Development Tools and Compilers
    • Development tools, e.g. IDEs and compilers, are not SOUP. They are used in the development environment and are not delivered to the end-user.
  • Software Development Frameworks
    • High-level software development frameworks like J2EE and ASP.NET are not SOUP. Similarly, lower-level frameworks delivered by microchips manufacturers are also not SOUP. These are used in the IDE at design time and are never delivered to the end-user.


Recipe for Handling SOUP in your Medical Device

The biggest concern with including SOUP in your medical device is how it will impact the overall safety of your device. However, there are established practices, defined in standards and guidance documents that help manufacturers to reduce the risk of using SOUP.

Once you have decided to include SOUP in your medical device, then the first step is to identify which market you are targeting. Thereafter, you need to handle the specific requirements of the applicable standards and regulations. While being compliant with IEC 62304 is a good start, often specific markets have requirements that are slightly different to IEC 62304.

Irrespective of the market, the general process for handling SOUP items in your medical device is:

  • Document the functional and non-functional requirements expected to be fulfilled by the SOUP
  • Document any (additional) requirements necessary for the SOUP item to work.
  • Select and document the SOUP and its characteristics/specifics
  • Analyse and control the impact of the SOUP on your medical device
  • Design your software architecture to include the SOUP
  • Include the SOUP in relevant tests to verify that it satisfies the requirements
  • Make sure that change management processes include the SOUP
  • Monitor the SOUP after your device has been released, most importantly to learn about new (major) bugs in the specific version you are using.


SOUP still too hot?

We understand that there is a risk with including SOUP into your otherwise high-integrity medical device. However, faithfully following the process to handle SOUP does mean that you can reduce the risk while benefitting from the fact that you don’t have to develop the functionality provided by the SOUP.

If you would like more information about SOUP or about how to best handle the inclusion of SOUP in your medical device then, please contact us at We will be happy to help you.

ArrowFast Team

ArrowFast Team

ArrowFast Team - A group of Medical Device Engineering Specialists

  • Mail Linkedin Twitter


Get the latest MedTech posts, news & a monthly newsletter delivered straight to your inbox.


Would you like to talk with our team about developing a new medical device or other MedTech related topics?