I have mentioned the need to validate software used in GxP regulated environments several times in previous posts. What you will find here is by no means intended to be a validation procedure, nor is it intended to be a complete guide to carrying it out, but only a small guide to help you understand what it means to carry out such an activity.
Software validation is a very demanding activity, both in terms of human and financial resources.
In fact, to validate a medium sized piece of software, such as an MES, you can expect to spend well over 100 man-days. This does not include internal resources.
It must also be borne in mind that in order for software to be considered valid, all the underlying part must also be validated, including the servers on which it is installed. In the case of virtual servers, both the virtual and physical servers must be validated.
The validation process must be part of the QMS of the company that intends to use the software. It is common to use external personnel with the appropriate experience for validation.
As we have already said: Any entity that can compromise the system being validated must be involved in the validation.
Software Validation Plan: So we're going to start by listing all of the software that's present in the company, and then we're going to weigh them up for impact, and that's how the Software Validation Plan is going to be completed.
Introduction: This is the first part to be included in the validation. It is a brief description of what we are going to validate.
Purpose: Once the key software has been identified, we will proceed to specify the purpose of the validation itself, identify the documents to be completed, define roles and responsibilities, and then proceed to plan all the relevant activities.
Scope: Having defined the purpose, it is necessary to specify the scope by writing a sentence such as "This Validation Plan applies to the HW and SW components of System xxx of Plant xxxx".
References: it is necessary that the validation includes all the references to the various procedures, both internal (SOPs), as well as references to any company procedures (if any), but also to any ISO, GAMP or Code Of Federal Regulation chapters.
Glossary: to enable an inspector to read the document independently, it is good practice to include a list of terms.
Validation strategy: based on a well-defined matrix, so as to show the critical points of the quality system, we then proceed to
1. Make a risk assessment by answering a series of standard questions.
Complete the "SW Criticality Question Table"; if at least one of the answers to questions 1-7 (1 to 7) is found to be "YES", THE SW UNDER EXAMINATION IS TO BE VALIDATED; if all of the answers to questions 1-7 (1 to 7) are found to be "NO", THE SW UNDER EXAMINATION IS NOT TO BE VALIDATED.
2-Part 11 Analysis; if we wanted to use saved records instead of paper, the system must also be in compliance with PART11
At this point, we have come to the point where we need to write the validation activities, which will consist of preparation:
1. Validation plan
2. User requirements
3. Functional specification
4. Configuration Specification
a. Design specification
b. Part 11 Analysis
c. Risk analysis
d. Installation/Operation/Performance Qualification
e. Operational Qualification Protocol
f. Performance Qualification Record
g. Installation/Operation/Performance Qualification Report
h. Operational Qualification Report
i. Performance Qualification Report
j. Test Traceability Matrix
k. Validation report
l. Definition of responsibilities
Please do not hesitate to contact me should you require further information.
コメント