Content area
Full text
The FDA (Food and Drug Administration) and IEC (International Electrotechnical Commission) requirements for validation of your manufacturing and quality system software can conjure up a lot of questions. Understanding the actual guidelines and best practices for meeting these requirements isn't always clear. Your software may be compliant, but you may not be. This article provides answers the top five most common software validation and documentation questions asked by others in FDA regulated industries and demonstrates best practices for meeting the guidelines.
What systems are considered Quality Systems?
The FDA mandates that software used for the design, manufacture, packaging, labeling, storage, installation, and servicing of all finished devices intended for human use shall be validated. While ISO (International Organization for Standardization) and SOX (Sarbanes-Oxley) regulations are not as clear about the validation process, they do require that software development lifecycle processes be followed in areas where they apply because software validation demonstrates evidence which provides a high degree of assurance that a specific process will consistently produce the expected result.
Your initial system assessment should provide you with the list of your systems which require validation. Below are eight of the most common systems. All of these systems fall under FDA regulation, but you can see from the connecting lines that ISO and SOX controls, also apply. The systems in red typically affect multiple business units within the organization, most of which are Configurable-off -the-Shelf (COTS) software systems. These systems allow you to configure the software to meet your business needs.
What documentation is required for Regulatory Validation?
The following documents are what auditors like to see in a Quality System Validation:
Software Validation Protocol; Network Diagram; Software Requirements Specification; Risk Analysis (the GAMP standard template is recommended); Part 11 Compliance Analysis; Design Specification (only for systems or areas of the system which contain custom code such as integrations between your Product Lifecycle Management (PLM) and Enterprise Resource Planning (ERP) systems) ; Test Plan; Test Specifications/Test Cases; and a Final Validation Report. These documents may be combined so long as you capture all of the information.
* Software Validation Protocol (Validation Plan)
This document outlines the project deliverables and responsibilities.
* System /Software Requirements Specification
This document details system requirements. However, this is more than just...





