Software Verification and Validation (V&V) Overview and must-have Documents

The regulatory bodies have specific verification and validation requirements for manufacturing and quality systems. However, there is not much understanding of the actual requirements and the best practices for meeting the requirements in the industry. The concerned personnel must understand how to meet the V& V requirements and draft a software verification and validation report package and protocol. This article presents an overview and reviews the must-have documents for V&V.

What is software verification and validation (V&V)?

Verification

820.3(a) Verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.

"Documented procedures, performed in the user environment, for obtaining, recording, and interpreting the results required to establish that predetermined specifications have been met" (AAMI).

Validation

820.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).

"Documented procedure for obtaining, recording, and interpreting the results required to establish that a process will consistently yield product complying with predetermined specifications" (AAMI).

Validation covers 3 activities as shown below:

What are the systems that require verification and validation?

FDA requirement

Any software that is used for the design, manufacture, packaging, labeling, storage, installing and services of all finished products intended for human use should be validated.

ISO (International Organization for Standardization) and SOX (Sarbanes-Oxley) requirement

Software development process should be followed in areas where they apply to ensure that a specific process will consistently produce the expected results.

When you make an initial assessment of your system, you can arrive at a list of systems that will require validation based on the regulatory requirements mentioned above. However, there are eight common systems that fall under the control of FDA, ISO, and SOX.

• Quality management system
• Calibration management system
• Maintenance management system
• Document management/PLM system
• Quality system platforms/server validation
• Resource management system
• Clinical data tracking databases
• Labeling software

Of the above, the Document management/PLM system, Resource management system, and Quality system platforms/server validations affect multiple business units and most of these are configurable-off-the-shelf (COTS) software systems.

What are the must-have documents for software system V & V?

1. Software Validation Protocol (Validation Plan): A document that outlines the project deliverables and responsibilities.
2. System /Software Requirements Specification
3. Network Diagram
4. Risk Analysis
5. 21 CFR Part 11 Compliance Analysis
6. Design Specification
7. Verification Protocol (Test Plan)
8. Test Specifications (Test Cases)
9. Requirements Traceability Matrix
10. Final Validation Report

1

2

The network diagram document is a document required to illustrate how the system is configured on the network. It provides proof that you have a grasp of how the system is configured for your implementation.

The safety of the application and identification of potential hazards is a critical requirement. The risk analysis document should evaluate safety and identify potential hazards. Rather than the traditional failure mode effect analysis (FMEA) risk assessment for the software program which are part of the device and pose a patient risk, this document should focus of the business processes that the system manages. While few risks are exclusively mitigated by the software, few risks are procedurally mitigated.

The 21 CFR part 11 contains specific requirements for the use of electronic signature. The compliance analysis document evaluates the system applicability/requirements for its use as specified in the regulation.

A document that indicates that the design criteria whereby the conformity with the requirement can be checked.

Contents of the verification protocol define the type of tests to be performed and the procedures and schedules for tests. Example: Acceptance criteria, materials traceability, pre and post-conditions, procedures, requirement tags, standards references.

Test cases are documents used in the process. In software verification and validation, they are used to determine if the product is built according to the user requirements.

This document links the requirements throughout the validation process. It ensures that all the requirements specified for a system are tested in test protocols.

Attend the webinar drafting a software verification and validation report package and protocol to take a deep dive into the documentation required by the U.S. FDA for the verification and validation planning and execution of software after basic developmental testing and de-bug. In this webinar a suggested field-tested 11-element FDA model will be evaluated, implemented, with V&V documentation and test case examples. The focus of the webcast is on the most recent issues the FDA has had in this area, and remediation approaches. Software considered: 1) In-product, 2) As-product, 3) Production and test, and 4) QMS / 21 CFR Pt. 11.

The instructor John E. Lincoln has over 33 years' experience in U.S. FDA-regulated industries and 20 years as a full-time consultant. He has worked with companies from start-up to Fortune 100, in the U.S., Mexico, Canada, France, Germany, Sweden, China and Taiwan.