FDA Expectations for Requirements

Some thoughts on Requirements … using the General Principles of Software Validation to help.

Many times we struggle with creating software requirements and documenting them.  The FDA General Principles of Software Validation-Final Guidance helps set the FDA expectations in this area.  Section 4.1 of the guidance states:

“A documented software requirements specification provides a baseline for both validation and verification.  The software validation process cannot be completed without an established  software requirements specification (Ref:  21 CFR 820.3(z) and (aa) and 820.30(f) and (g)).”

When researching the referenced regulations, we see:
1) 21CFR820.3(z)

Validation means confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use can be consistently fulfilled.

    1. Process validation means establishing by objective evidence that a process consistently produces a result or product meeting its predetermined specifications.
    2. Design validation means establishing by objective evidence that device specifications conform with user needs and intended use(s).”

2) 21CRF820.30(f)

Design verification. Each manufacturer shall establish and maintain procedures for verifying the device design. Design verification shall confirm that the design output meets the design input requirements. The results of the design verification, including identification of the design, method(s), the date, and the individual(s) performing the verification, shall be documented in the DHF.”
3) 21CFR820.30(g)
Design validation. Each manufacturer shall establish and maintain procedures for validating the device design. Design validation shall be performed under defined operating conditions on initial production units, lots, or batches, or their equivalents. Design validation shall ensure that devices conform to defined user needs and intended uses and shall include testing of production units under actual or simulated use conditions. Design validation shall include software validation and risk analysis, where appropriate (Note: it’s always appropriate!). The results of the design validation, including identification of the design, method(s), the date, and the individual(s) performing the validation, shall be documented in the DHF.”
One can understand very quickly that FDA’s view of software requirements is that requirements will have a role in Design Verification activities and in Design Validation activities.  One should be cognizant of that as they plan specific design verification and design validation tasks.  In many cases, these will overlap offering opportunities for efficiency and diverse testing methodologies.
Whether one is creating software for a simple, low risk medical device or HealthIT, or complex, high risk safety-intense medical device software, the GPSV specifies documented software requirements.  By documented, one should conform with their 21CFR820.40 compliant process.  However, how the documentation is captured during development and managed can be very flexible.
Requirements must be measurable and testable … otherwise design verification tasks may be difficult and/or unable to be completed.  Generally, software requirements answer the question of “what should the software do.”  Software design specifications should describe the detailed software design for achieving the software requirements.

Final thought:  Notice the word “baseline.”  One should be sure to understand the baseline software requirements for any external release of software.  Plan how the baselines will be managed and associated configuration management activities.

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.