Understanding OTS and SOUP

Understanding OTS and SOUP

Understanding OTS and SOUP is very important in every lifecycle stages of medical device and HealthIT software development.  In the late 1990’s, the US FDA first published guidance documentation on the use of Off-The-Shelf (OTS) software in medical devices (or sometimes referred to as “OTSS”).  At that time, OTSS generally accounted for a very small fraction of the executing software in medical device.  Since that time however, the use of OTS software in medical devices has steadily increased to where many of today’s medical devices, particularly “Software as a Medical Device (SaMD),” operate with the majority of the overall software in the product being OTSS.  In 2019, FDA updated the previous guidance (2019-Off-The-Shelf Software-FDA).  The opening paragraph of the guidance points out:

  • OTSS use has expanded along with use of general-purpose computer hardware
  • The premise of OTSS use is that it allows the manufacturer to concentrate on the application software
  • OTSS may not be appropriate for a given specific use in a medical device
  • The manufacturer using OTSS generally gives up software life cycle control, but still bears the responsibility for the continued safe and effective performance of the medical device

As with all software in medical devices, the use of OTSS must be guided using the safety risk management process.  The key activity in the risk management process for OTSS would be identifying all of the hazardous situations for which failures of the OTSS could contribute.  This is not a trivial activity – so while the use of OTSS can save development time, it requires MORE risk analysis time.

Related to the US FDA “OTS” acronym is the concept of “SOUP” defined in IEC 62304 (link to the popular FAQ on 62304 (62304 FAQ)).  IEC 62304 defines SOUP as “software of unknown provenance.”  What is meant by that?  The standard provides this definition.   SOUP is a software item that is:

  1. already developed and generally available and that has not been developed for the purpose of being incorporated into the medical device; or
  2. software previously developed for which adequate records of the development processes are not available (often called “legacy”)

Essentially SOUP is software for which the manufacturer lacks sufficient records to establish conformance with IEC 62304.  Of course we understand that the missing (or non-existent) records are the common types of records one creates when designing higher quality software, namely:

  • planning
  • software risk analysis
  • software requirements
  • software architecture and design
  • software unit verification
  • software integration verification
  • software system verification
  • software release documentation

The use of OTSS and/or SOUP can have advantages and disadvantages – one must consider both in planning its use.  Understanding OTS and SOUP should be a key training element for software project teams.

Image:  Shmuel Csaba Otto Traian, CC BY-SA 3.0 <https://creativecommons.org/licenses/by-sa/3.0>, via Wikimedia Commons

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.

Upcoming Training

Agile Methods for Medical Device and Health IT Software

One day course that expands on the software risk management topics covered in our IEC 62304 and other Emerging Standards for Medical Device and HealthIT Software course. Essentially the same topics are covered but in greater depth with more attention to hands-on analysis of examples.

Email training@softwarecpr.com for more info.

Corporate Office

15148 Springview St
Tampa, FL 33624
USA
+1-781-721-2921
Partners located in the US (CA, FL, MA, MN) and Italy.