Available as PDF
MS WORD 

    
PRODUCTS

     
ISO 9001-2008
       
ISO/TS 16949:2009
FDA Requirements - 
Checklist Kit
 
Template-Kit for Software Engineering Management
ISO/IEC 90003 Supplier Assessment Checklist
ISO/IEC 90003 for Computer Software - Checklist
ISO 9004:2009 - Checklist
FDA 21 CFR - Checklist
ISO/IEC 15288:2008 - Life Cycle  - Checklist
FDA Guidance for pre-market submissions
FDA Software Validation
FDA Off-The-Shelf Software
ANSI/AAM/ISO 13485 - Checklist
     
ANSI/UL 1998 - Checklist
Software Engineering
     
IEC 62304 Checklist 
IEC 60601-1-4 Checklist 
     
IEC 60601-1-3 b - Checklist 
     
ISO/IEC 12207:2008 Requirements Checklist
ISO/IEC 27002:2005 - Checklist
ISO/IEC 20000-1:2005 Checklist

    
General

                   
 Macular Degeneration
Technical Dictionary
 English / Spanish
 

   

Sample Pages


FDA Document

General Principles of Software Validation

Final Guidance for Industry and FDA Staff

 

 

Available as:
PDF
  MS WORD
   

 

Introduction
The process of defining what is necessary for compliance with a software engineering process standard or guide such as “General Principles of Software Validation; Final Guidance for Industry and FDA Staff” is often confusing and laborious because the directions contained in the standards or guides are unclear or ambiguous. To aid in determining what is actually “required” by the document in the way of physical evidence of compliance, the experts at SEPT have produced this checklist. This checklist is constructed around a classification scheme of physical evidence comprised of policies, procedures, plans, records, documents, audits, and reviews. There must be an accompanying record of some type when an audit or review has been accomplished. This record would define the findings of the review or audit and any corrective action to be taken.  For the sake of brevity this checklist does not call out a separate record for each review or audit. For this checklist “manuals, reports, scripts and specifications” are included in the document category. 
SEPT has carefully reviewed the document “General Principles of Software Validation; Final Guidance for Industry and FDA Staff” and defined the physical evidence required based upon this classification scheme. SEPT has conducted a second review of the complete list to ensure that the documents’ producers did not leave out a physical piece of evidence that a “reasonable person” would expect to find. It could certainly be argued that if the document did not call it out then it is not required; however if the standard or guide were used by an enterprise to improve its process, then it would make sense to recognize missing documents. Therefore, there are documents specified in this checklist that are implied by the standard or guide, though not specifically called out in the document, and they are designated by an asterisk (*) throughout this checklist.  If a document is called out more than one time, only the first reference is stipulated. 

There are occasional situations in which a procedure or document is not necessarily separate and could be contained within another document. For example, the Software Detail Specification Document could be a subset of Software Design Specification. SEPT has called out these individual items separately to ensure that the organization does not overlook any facet of physical evidence. If the organization does not require a separate document, and an item can be a subset of another document or record, then this fact should be denoted in the detail section of the checklist for that item. This should be done in the form of a statement reflecting that the information for this document may be found in section XX of Document XYZ. If the organizational requirements do not call for this physical evidence for a particular project, this should also be denoted with a statement reflecting that this physical evidence is not required and why. The reasons for the evidence not being required should be clearly presented in this statement. Further details on this step are provided in the Detail Steps section of the introduction. The size of these documents could vary from paragraphs to volumes depending upon the size and complexity of the software project or business requirements.

General Principles of Software Validation Checklist
This checklist was prepared by analyzing each clause of this draft document for the key words that signify a:

  • Policy
  • Procedure
  • Plan
  • Records
  • Document ( Including Manuals, Reports, Scripts and Specifications)
  • Audit
  • Review
This checklist specifies evidence that is software or system unique. After reviewing the completed document, the second review was conducted from a common sense “reasonable man” approach. If a document or other piece of evidence appeared to be required, but was not called out in the document, then it is added with an asterisk (*) after its notation in the checklist. The information was transferred into checklist tables, based on the type of product or evidence.

Using the Checklist
When a company is planning to use “General Principles of Software Validation” as their software validation document for a project the company should review the evidence checklist. If the company’s present process does not address a “General Principles of Software Validation” product, then this question should be asked: “Is the evidence product required for the type of software the business is producing?” If in the view of the company the evidence is not required, the rationale should be documented and inserted in the quality manual. This rationale should pass “the reasonable person rule.” If the evidence is required, plans should be prepared to address the missing item(s). 

Detail Steps
An enterprise should compare the proposed output of their software project or organization against the checklist. In doing this, they will find one of five conditions that exist for each item listed in the checklist. The following five conditions and the actions required by these conditions are listed in the table below.
 

 

Condition
Action Required
1. The title of the documented evidence specified by the checklist (document, plan, etc) agrees with the title of the evidence being planned by the enterprise.  Record in checklist that the enterprise is compliant.
2. The title of the documented evidence specified by the checklist (document, etc) disagrees with the title of the evidence planned by the enterprise but the content is the same.  Record in the checklist the evidence title the enterprise uses and record that the enterprise is compliant, and the evidence is the same although the title is different. 
3. The title of the documented evidence specified by the checklist (document, etc) is combined with another piece of evidence.  Record in the checklist the title of the evidence (document, etc) in which this information is contained.
4. The title of the documented evidence specified by the checklist (document, etc) is not planned by the enterprise because it is not required. Record in the checklist that the evidence is not required and the rationale for this decision.
5. The title of the documented evidence called out by the checklist (document, etc) is not planned by the enterprise and should be planned by it. Record in the checklist when this evidence will be planned and reference a plan for accomplishing the task. 

 


Components of the Checklist 
This checklist is composed of 8 sections:
  • Section 1.  Introduction
  • Section 2.  Composites of all required and suggested “General Principles of Software Validation” evidence products.
  • Sections 3-7.  Individual checklists for each evidence type.
  • Section 8.  “About the Author”
Product Support 
All reasonable questions concerning this checklist or its use will be addressed free of charge for 60 days from time of purchase, up to a maximum of 4 hours consultation time.
 

 

4. Principles of Software ValidationPRINCIPLES OF SOFTWARE VALIDATION CLAUSE NUMBER AND NAME
POLICIES and PROCEDURES
PLANS
RECORDS
DOCUMENTS
AUDITS and REVIEWS
2.0 Scope              .
2.1 Applicability              .
2.2 Audience              .
2.3 The Least Burdensome Approach             .
2.4 Regulatory Requirements for Software Validation
  • Guidance for Industry, FDA Reviewers, and Compliance Off-the Shelf Software Use in Medical Devices Requirements for Procedures*
  • Guidance for Industry, FDA Reviewers, and Compliance Off-the Shelf Software Use in Medical Devices Requirements for Plans*
  • Guidance for Industry, FDA Reviewers, and Compliance Off-the Shelf Software Use in Medical Devices Requirements for Records*
  • Guidance for Industry, FDA Reviewers, and Compliance Off-the Shelf Software Use in Medical Devices Requirements for Documents*
  • Guidance for Industry, FDA Reviewers, and Compliance Off-the Shelf Software Use in Medical Devices Requirements for Audits*
  • Guidance for Industry, FDA Reviewers, and Compliance Off-the Shelf Software Use in Medical Devices Requirements for Reviews*
2.5 Quality System Regulation VS Pre-Market submissions             .
3.0 Context for Software Validation              .
3.1 Definitions and Terminology             .
3.1.1 Requirements and Specifications             .
3.1.2 Verification and Validation
  • FDA’s Guidance for the Content of Pre-market Submissions for Software Contained in Medical Devices Requirements for Procedures*
  • IEC 60601-1-4 Requirements for Procedures*
  • ISO 14971-1 Requirements for Procedures*
  • FDA’s Guidance for the Content of Pre-market Submissions for Software Contained in Medical Devices Requirements for Plans*
  • IEC 60601-1-4 Requirements for Plans*
  • ISO 14971-1 Requirements for Plans*
  • FDA’s Guidance for the Content of Pre-market Submissions for Software Contained in Medical Devices Requirements for Records*
  • IEC 60601-1-4 Requirements for Records*
  • ISO 14971-1 Requirements for Records*
  • FDA’s Guidance for the Content of Pre-market Submissions for Software Contained in Medical Devices Requirements for Documents*
  • IEC 60601-1-4 Requirements for Documents*
  • ISO 14971-1 Requirements for Documents*
  • FDA’s Guidance for the Content of Pre-market Submissions for Software Contained in Medical Devices Requirements for Audits*
  • FDA’s Guidance for the Content of Pre-market Submissions for Software Contained in Medical Devices Requirements for Reviews*
  • IEC 60601-1-4 Requirements for Audits*
  • IEC 60601-1-4 Requirements for Reviews*
  • ISO 14971-1 Requirements for Audits*
  • ISO 14971-1 Requirements for Reviews*
3.1.3 IQ/OQ/PQ              
3.2 Software Development as Part of System Design             
3.3 Software Is Different From Hardware              
3.4 Benefits of Software Validation             
3.5 Design Review           
  • Design Reviews
4. Principles of Software Validation                
4.1 Requirements        
  • Software Requirements Specification Document
 
4.2 Defect Prevention          
4.3 Time and Effort          
4.4 Software Life Cycle
  • Life Cycle Selection Procedure
   
  • Life Cycle Selection Procedure Review
 
4.5 Plans  
  • Verification and Validation Plan
     
4.6 Procedures           
4.7 Software Validation After a Change          
4.8 Validation Coverage      
  • Validation Document
 
4.9 Independence of Review          
4.10 Flexibility and Responsibility          
5.0 Activities and Tasks          
5.1 Software Life Cycle Activities          
5.2 Typical Tasks Supporting Validation