Computerized system validation (CSV) (usually referred to as "Computer Systems Validation") is the process of testing/validating/qualifying a regulated (E.g., FDA 21CFR11) computerized system to ensure that it does exactly what it is designed to do in a consistent and reproducible manner that is as safe, secure and reliable as paper records. This is widely used in the Pharmaceutical, Life Sciences and Biotech industries and is a cousin of Software Testing but with a more formal and documented approach. The validation process begins with the system proposal/requirements definition and continues until system retirement and retention of the e-records based on regulatory rules.
Need for Computer System Validation:
When any equipment breaks down, there are obvious symptoms through which a catastrophic event can be avoided. Computer system breakdowns are often very complex and very difficult to recognize, and its outcome might prove to be very serious.
Drug companies, Arline industry, nuclear power plants and many other industries very quality of the product is of utmost importance have seen very expensive consequences from improper computer system operation. Many of these consequences cost more than the cost of computer system validation (CSV).
CSV Validation in Pharma - Significant increase in the use of computer-related system in the life sciences industries and the need for them to practice the cGMP (Current Good Manufacturing Practice), CSV plays a crucial role here. (Become a certified GMP Professional)
Several approaches for software validation exists and may be appropriate for a specific project. The scope of validation effort depends upon number of factors
1. Size and complexity of the software.
2. Origin of the software.
3. Critical or non-critical functionalities.
By effectively planning the process, validation time and resources can be reduced while following the regulatory requirements.
Methodology of CSV:
The following figure depict the method for CSV:
Validation activities follow the diagram beginning at the top left (Planning), proceeding down the V-shape to System Build and then back to the top right, ending at Reporting.
Validation Plan
The Validation Plan defines what will be validated and the approach you will use. It also defines roles and responsibilities along with the most important part, the Acceptance Criteria.
User Requirements Specification (URS)
The User Requirements Specification describes what the user needs from the software and how they will use it. It also contains any critical constraints such as regulations, safety requirements, operational requirements, etc.
For example, here’s a list of a few User Requirements that might be needed for a lab system.
· System must track training of lab analysts on lab methods/techniques
· System must track samples coming into the lab
· System must automatically assign lab analysts to test samples based on availability and training
· System must send sample testing pass/fail outcomes to the ERP
· System must comply with 21 CFR 11
Functional Specifications (FS)
The Functional Specification document describes how the software needs to work and look to meet the user needs. The document might include descriptions of how specific screens and reports should look, or describe data that needs to be captured.
The Functional Requirements can also include logic and calculations along with how it will comply with regulatory requirements. For example, the Part 11 compliance requirements might detail how passwords or the audit trail should work.
Design Specifications (DS)
The Design Specification document is one that contains all of the technical elements of the software or systems. This includes:
· Database Design – file structures, field definitions, data flow diagrams, entity relationship diagrams
· Logic/Process Design – pseudo code for logic and calculations
· Security Design – virus protection, hacker protection
· Interface Design – what data will move from one system to another; how and how often, and failure handling
· Architecture Design – required hardware, operating systems, application versions, middleware, etc.
· Network Requirements
· Specific peripheral devices – scanners, printers, etc.
System Build
In the System Build step, you develop or purchase your software and then configure it to the previous specification documents. This step includes unit testing and integration testing.
Installation Qualification Tests (IQ) Tests
The Installation Qualification tests provide confirmation that the software or system is installed and setup according to the Design Specification. Usually the software is first installed in a test or validation environment, but there can be exceptions in situations such as manufacturing.
Operational Qualification (OQ) Tests
Operational Qualification testing is often referred to as Functional Testing or System Testing. OQ tests confirm that all functionality defined in the Functional Specification is present and working correctly, and that there are no bugs. OQ tests can also include confirmation of any design elements not tested during IQ, such as configuration, are working as specified.
Performance Qualification (PQ) Tests
Performance Qualification testing is often called User Acceptance testing. PQ testing confirms that the software will meet the users’ needs and is suitable for their intended use, as defined in the User Requirements Specification. Testing can follow Use Cases, SOPs, user-defined scenarios, etc. For simple software like reports or spreadsheets, OQ and PQ testing are often combined.
Reporting
The last step in this validation method is to write the Validation Report, often called the Validation Summary or System Certification. This report provides confirmation that all activities specified in the validation plan have been completed. The Validation Report summarizes the testing results and provides confirmation that all acceptance criteria have been met and the software is ready for deployment.
Various terminologies used in validation:
To know what CSV is and it works, we must be well verse in the terminologies commonly used in the validation process.
Software Verification
FDA states that, Software verification looks for consistency, completeness, and correctness of the software and its supporting documentation, as it is being developed, and provides support for a subsequent conclusion that software is validated. Verification confirms and reviews tasks within the validation process.
Validation
According to FDA, Validation is confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled.
Qualification
Qualification is defined by IEEE (world’s largest technical professional organization dedicated to advancing technology for the benefit of humanity) as, Formal testing to demonstrate that the software meets its specified requirements.
To put all the terms together, look at the following figure,
Scope of CSV:
CSV has wide range of scope. It can be used to validate following software’s,
1. Medical Device Software: Software used as a component, part, or accessory of a medical device. Software that is itself a medical device.
2. Production Software: Software used in the production of the FDA regulated product
3. Quality Management Software: Software used to implement the FDA-required quality management system
4. Software for FDA-Regulated Records: Software used to create, modify, maintain, archive, retrieve, or transmit FDA-required records. And electronic records submitted, per FDA requirement.