(GxP) and is in the food, pharmaceutical products, or medical devices business sectors, then you are likely required to comply with a regulatory agency. Failure to comply with regulations could lead to fines, suspension of business, or even loss of your business. This article will provide an overview of a software validation for a computer software system to be compliant with Food and Drug Administration (FDA) regulations.
Computer software can be employed within an organization to gain efficiency or perform functions that are specialized. Software can consolidate data and make data analysis more effective or flexible. For all of the positive things software can provide, it is not a magic bullet that will solve problems without understanding the requirements for obtaining the desired results. Understanding the scope and requirements of processes that the software will be employed is the first step in executing a successful software validation.
Gathering requirements is a critical step for implementation of software. Documentation of features and functions will provide the validation process with the information needed to develop the appropriate test scripts that will demonstrate all requirements are satisfied. Within the requirement phase, the documents produced will include:
Feature Request Specification (FRS) / Business Process Analysis (BPA)
This is step provides the high level overview of all processes for which the intended software solution will cover. If the software will replace manual processes, then examples of the manual process should be included. When no manual process already exists, a map of the intended process should be developed. The software scope is defined and the type of software solution is determined. The type of software could be a commercial off the shelf (COTS) solution or a custom development solution.
Software Requirement Specifications (SRS)
Whether the software solution selected is custom or COTS, the SRS will detail each feature and function required from the processes or procedures defined in the FRS or BPA. Each statement within the SRS is written in precise and explicit language such that it will become a testable item for the validation process. Approval by all appropriate parties is required and once the SRS has been signed, no changes can be made to the signed version. Subsequent versions of the SRS require the re-execution of the approval and validation cycle.
The SRS is one of the most important documents within the software implementation process. It becomes the blueprint with which all validation results will refer back to.
Software Design Specifications (SDS)
When custom software development is required, the SDS document provides the development plan for the software code. This document will detail the technology, development tools, software architecture and parameters to be implemented in the software code during the development of the software solution.
Software development and Installation
Once you have the above requirement phase complete, you should have the roadmap for the tasks required to reach the goal of system installation. Timelines developed from the requirement documentation will account for all development, testing and installation of the software solution. During this cycle, all changes and deviations need to be recorded and updated in the documentation with appropriate approval steps followed.
Custom development systems will require the development of installation and configuration procedures and documentation. If the software system is a COTS system, the vendor will need to provide you with concise and complete documentation for installation and configuration of the software. These documents will accompany the System Configuration Specifications (SCS) document. The SCS captures all software installation/configuration, hardware, network, and environment details. The purpose of the SCS is in part for disaster recovery planning.
Validation Preparation
Validation personnel should be consulted during the requirement and development phase of the project. During this time, validation personnel can begin preparation and planning for the validation testing, but test script development will be limited until a development environment has been installed with the software system. Once a full development environment has been setup, the validation team can engage directly in preparing the required validation documentation. The documentation produced in this phase will include:
Installation Qualification (IQ)
The IQ document is a set of test scripts used to verify that all software and equipment has been installed correctly and meets the specifications defined in the SRS. The development of the test scripts will determine if all installation and configuration instructions have been executed and followed as written, thus it is important that there are no ambiguous parameters or instructions contained within the installation documentation or SCS. If the installation instruction provides alternative configuration methods, the specific configuration will be defined by the SCS. The IQ testing is limited to the static attributes of the system and subsystems prior to operation.
Operational Qualification (OQ)
The OQ document is a set of test scripts used to verify that the operation of features and functions within the software system meet the specifications defined in the SRS. These test scripts will target not only specific function and feature, but also will test processes, security, and data integrity. Each test will relate to one or more SRS items.
Performance Qualification (PQ)
The PQ document is a set of test scripts used to verify that the expected daily performance is acceptable. These test scripts verify that the system will give consistent results under load and predetermine SRS criteria.
User Acceptance Test (UAT)
The UAT is a set of test scripts used to verify the intended daily operation of the system within your environment. These tests will closely mimic the procedures and processes executed during the course of regular business operations.
Reverse Tractability Matrix (RTM)
The RTM provides the direct links between the SRS and IQ/OQ/PQ/UAT tests. For each SRS item, the validation test scripts that verify the expected result are listed. This provides any party involved the ability to audit the validation results and determine if all expectation of the software have been satisfied.
Standard Operating Procedure (SOP)
The Standard Operating Procedures will be a set of documents detailing the steps and procedures required in the operation, maintenance, backup and recovery of the software system. These documents also specify who is responsible for tasks and when actions are to be performed. The SOPs are not exclusive to the software system. The SOPs generated here are part of the entire company Standard Operating Procedures.The software validation documents prepared will need to be dry run by quality assurance personnel to verify that the test scripts execute cleanly. Language is an important component of the test scripts. Dry runs will
identify any ambiguous instructions and mistakes within the test scripts. At the point where all the validation documentation has been verified, all documents will be versioned, approved and signed by the responsible parties involved. Once this has occurred, no further changes can be made to documents without repeating the approval process on any change. The approval of validation documents is required before execution of validation can begin.
Now it’s Time to Validate
The install processes developed above are executed to create a testing environment for the software system. The quality assurance personnel will execute the validation plan, recording all results and deviations. On completion of validation process within the testing environment, all documentation will be signed and approved with all exceptions and deviations accounted for.
Provided there are no deviations or exceptions recorded that violate compliance regulations, the production environment can be installed and validated. The production environment will follow the same procedure as the testing environment.
Acceptance
After all validation documents have been executed without any unacceptable deviation or exceptions, the final acceptance of the system can be done. The acceptance criteria for the completion of system testing will include:
- Successful completion of the testing developed according to the Validation Plan for each test component.
- Approval of all test documents for each test component.
- All SRS requirements have been verified in the working test and production systems.
- Proper recording of any reported variances and appropriate corrective actions for closure applied to each variance.
- Assurance that the number and/or nature of reported variances for each test component do not compromise the intent or integrity of the software implementation as determined by test document post reviewers.
After the system has been accepted, you will need to train personnel for daily operations. Along with training, the SOPs will be implemented and official release of the system is required.
Conclusion
The validation process provides the evidence required to prove that a system or process operates as designed and complies with any industry regulations. Validation also provides you with a greater depth of understanding about your systems or processes. If your validation has been well designed, it has greater benefits than just being compliant; it can also provide a greater level of control to your business. The documents described above are part of a living process. Any software updates or patches require validation that will follow updates to initial validation plan. These subsequent validation cycles may be scaled down from the initial validation, but the result will extend the unbroken historical line of the system or process.