SOUP – Can’t Live Without It!

Software of Unknown Provenance


SOUP.  It is likely that you are familiar with the acronym, SOUP, in relation to medical device and Health IT software.  The medical device software standard IEC 62304, defines SOUP as a “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.

When I started my career in the mid-1980’s, we developed most ALL of the software in our medical devices.  Very little SOUP was used.  However, in 2021, most medical devices and Health IT systems are composed primarily of SOUP!  Wow, what a transition!

We are often asked about SOUP from a compliance standpoint.  One of the major confusions is confusing SOUP used in our products (which are subject to IEC 62304) with SOUP that may be used in our development and other quality system tools (which are not subject to IEC 62304).  IEC 62304 is concerned with the quality of the software running in your medical devices (including SaMD).

A second confusion is artificially gather SOUP documentation separately then where it would naturally apply.  For example, having a separate SOUP software risk analysis from the custom software risk analysis.  Likely, SOUP failure modes are in the same fault trees as your custom software so it would be easiest for the software development team to do the software risk analysis of custom software and SOUP at the same time and document it in the same way.  This applies to all places where SOUP should be considered in the entire SDLC.

Don’t create unnecessary work simply because you think that it is required for compliance.  That is not the intent of IEC 62304 nor of the US design controls regulations.  Sometimes we may see these separate documentation tasks as improving quality – but in fact, they could have the opposite effect! The time invested by the software development teams creating unnecessary documentation could have in fact been invested in greater rigor and detail for safety related software.

Gotta use SOUP?  I get it – but analyze its failure modes and design in risk controls.  We will all benefit from it.  Onward!

About the author

Brian Pate helps medical device companies achieve efficient and FDA regulatory compliant product development to produce higher quality and clinically valued software. He began his career in clinical research in 1985 with the Department of Anesthesiology at UAB developing closed-loop control systems for the automated delivery of gases and control. In 1990, he made the switch from university research to the medical device industry designing control systems, communication interfaces, user interface, and other software for real-time embedded systems and clinical information systems, working for medical device companies including Johnson & Johnson, Baxter Healthcare, and GE Medical. Today, he is a Partner and the General Manager of Crisis Prevention and Recovery LLC (dba SoftwareCPR®), a general-purpose regulatory consulting firm that is recognized globally for their expertise with standards and national regulations pertaining to medical device, mobile medical app, and HealthIT software. He has taught the AAMI/FDA course on Software Regulation to FDA Reviewers at FDA and is currently the lead faculty for the public version of that course taught annually along with FDA staff. Brian served on the AAMI/FDA TIR working group that created AAMI TIR32 Guidance on the application of ISO 14971 to Software (later superseded by IEC 80002-1). He later served on the original AAMI/FDA working group that created the AAMI TIR45-2012 TIR Guidance on the use of Agile practices in the development of medical device software and is currently the co-chair leading the creation of the 2nd edition of TIR45. He has served as faculty for all offerings of the AAMI/FDA Compliant Use of Agile Methods public course. Brian also served as an instructor for the AAMI Design Controls course. He is also a member of the Underwriters’ Laboratories Standards Technical Panel 5500, Remote Software Updates. He now serves as a member of the AAMI Software Committee.

Cybersecurity Review

Our cybersecurity experts are NESSUS Pro Licensed and can quickly remediate cybersecurity deficiencies with your medical device or digital health software.  Planning, requirements, validation, and submissions – we can assist with all.

Interested in having a conversation?  Email us to arrange a Zoom meeting or call us at +1 781-721-2921.

Corporate Office

15148 Springview St
Tampa, FL 33624
Partners located in the US (CA, FL, MA, MN), Canada, and Italy.