Brian Shoemaker, Ph.D., who clearly has expertise on software quality and FDA, (see http://www.shoebarassoc.com/; Brian has more than thirteen years’ experience with software quality and validation in the FDA-regulated industry) added an in-depth comment describing additional documentation guidance for doing software V&V. He also provides his opinion on applicability of agile in this world (just do it?) as well as some implications for updates to the companies QMS. Since wordpress comments aren’t partriculary reader-facing-friendly, and there is real value in his comments, I’ve reposted excerpts here:
“Thanks for putting together the comments you’ve published here……. FDA has other guidances relevant to software besides the Design Control Guidance and General Principles of Software Validation, though those two are certainly the most important.
A more complete list would be:
- Design Control Guidance For Medical Device Manufacturers (March 11, 1997)
- General Principles of Software Validation (January 11, 2002)
- Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices (May 11, 2005)
- Off-The-Shelf Software Use in Medical Devices (Sep. 9, 1999)
- Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software (Jan. 14, 2005)
- Computerized Systems Used in Clinical Investigations (May 2007 – note this is not directly relevant to medical device software)
- 21 CFR Part 11: Electronic Records and Signatures (Aug. 1997)
- Draft Guidance: Radio-Frequency Wireless Technology in Medical Devices (PDF) (January 3, 2007)
The “Premarket Submissions” guidance (third in the list) is often misread as specifying what processes a firm needs to use based on the hazard classification of the device (termed “Level of Concern” in the guidance). This is not the intent at all – rather, the guidance states what documents should be SUBMITTED based on the Level of Concern; the documents should exist anyway, whether they’re submitted or not.
I’ve argued for several years, just as you do, that nothing in GPSV specifies that medical device developers are required to use a waterfall approach.
In the October 23 post, you interpret the various activities required for Design Control. I disagree that waterfall methodology is implied here, but I can see how that interpretation can slip in – and I’ve worked with plenty of clients who believed that a waterfall approach is required.
Notice that the terms in the Design Control section of Part 820 all come directly from ISO 9000 (or ISO 13485, its medical device half-brother). I’m convinced that one can match up every quality-related activity in a software process (i.e. quality planning, requirements development, design and coding, configuration management, defect tracking) with an appropriate subparagraph in part 820.
Also notice that “verify” and “validate” are ISO 9000 concepts.
In the projects I’ve worked on with client companies, the “Product Requirements Document” or “System Requirements Specification” originated with Marketing, for better or worse (the marketing folks are often harder to train than engineers when it comes to concisely and clearly expressing requirements).
The concept of a “define-build-verify” team is powerful enough that, in my opinion, it should be described in a planning document (Software Development Plan or Quality Plan, depending on how the company structures such things). Planning documents not only outline steps to be followed, but give specific responsibility for specific steps – describing the team’s structure and tasks are important not only for the participants but also for the reviewer who checks the documentation after the fact.”
end of Brian’s quote…….