Software Design Specifications

Software Design Specification

What does the US FDA expect in a premarket submission for description of the software design?  In the recent June 2023 Guidance for Industry and Food and Drug Administration Staff titled, “Content of Premarket Submissions for Device Software Functions,” the FDA gives the following guidance.

For lower risk devices, the manufacturer is not required to send any software design specification documentation.  Be aware that the agency could still ask for software design information during the clearance or approval process.  Also keep in mind that even though not required in the regulatory submission, software design specifications could likely be reviewed during an FDA regulatory inspection.

For device software functions where a failure or flaw of any device software function(s) could present a hazardous situation with a probable risk of death or serious injury, more documentation is required and, in particular, software design specifications are required.  How much more?  Here are the key expectations for software design specification documentation.

Can be one or more documents.  Documentation should include:

  1. Software functionality
    Functionality should be described in context of the high level defined in the system and software architectural documentation.
  2. How the software design implements the SRS
  3. Trace of software design to the SRS in terms of:
    1. Intended use
    2. Functionality
    3. Safety and effectiveness

FDA makes clear that software design is expected to have “occurred as a prospective activity where the SDS was used to guide the design, development and testing of the software rather than documented retrospectively after the software design has been implemented by ad hoc design methods.

Other related posts:

Software Risk Analysis

About the author

Partner and General Manager, Brian Pate is ISO 1385:2016 Lead Auditor certified for Medical Device Quality Management Systems (MD), and ISO 19011:2018 Management Systems Auditing (AU) and Leading Management Systems Audit Teams (TL). Brian started his medical device career in anesthesia clinical research in 1985 and has since worked both academia and industry including many years with Johnson & Johnson, Baxter Healthcare, and GE Medical. Brian’s roles have included software engineering, systems engineering, quality assurance, and regulatory affairs. Brian has served on multiple AAMI TIR working groups, including TIR32-2008 (Application of ISO 14971 Risk Management to Software; now IEC 80002-1) and TIR45-2012 (Guidance on the use of Agile practices in the development of medical device software) and served as a reviewer for the 2nd edition of TIR45. Brian serves on the AAMI Software Committee and as an AAMI instructor for the software, design controls, and agile methods courses. Brian also is a member of the Underwriters’ Laboratories (UL) Standards Technical Panel for UL1998 (Software in Programmable Components) and or UL5500 (Remote Software Updates).

SoftwareCPR Training Courses

ISO13485:2016 ISO 13485 Internal Audit(or) Training Course (Live, 3-day)

IEC 62304 and other Emerging Standards Impacting Medical Device Software (Live, 3-day)

Being Agile & Yet CompliantISO 14971 SaMD Risk Management

Software Risk Management

Medical Device Cybersecurity

Software Verification

IEC 62366 Usability Process and Documentation

Or just 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, TX) and Canada.