|
Validating Software used for the Pharmaceutical Industry |
The Validation SOP and the Required Documentation
Since you are looking at this web site you either work for a Pharmaceutical corporation or a contract research organization (CRO). You or your company may have just created or purchased a program or computerized system. You should be congratulated on your hard work and creativeness for taking this system from inception to the production stage. For this initiative you will now be punished. You see if this system helps contribute to a regulatory submission (submission to the American Food and Drug Administration [FDA], European Agency for Evaluation of Medicinal Products [EMEA] or any other international agency) the system has to be validated. I am going to describe to you what is involved with validation and the steps needed to carry out validation of your system by helping you create a validation Standard Operating Procedure (SOP). In other words, we will create an SOP which will guide you through all the steps that must be preformed to validate your system.
Before we do anything, you first need to raise your right hand and say this out load, "I am reading this for informational purposes and I understand that by following the instructions laid out in this document the author does not guarantee that the validation documents produced will pass an audit by the FDA, international regulatory agency or a client." In other words don't blame me if your validation package doesn't pass an audit.
Why did I create this instructional web site? I want people to know that validation can be done in-house and I want to give people a plan to follow that will result in a successful and defensible validation package.
One thing to remember before we start, validation is costly and time consuming but in the end it is much cheaper then failing an audit.
The Validation SOP
Write a Standard Operating Procedure (SOP) which describes your validation process.
The SOP will serve as a guide for you to carry out the validation. By writing the SOP you will have two essential items:
- The SOP itself which you must show to an auditor
- Templates will be created that will be used to
structure your validation process.
Remember an auditor will look at your validation SOP and compare it with the documents produced during validation (validation package). The auditor will be looking to see that you followed what is written in the SOP. Also, remember no matter who does the validation (you or a contractor) it can take time. It is better to do a thorough validation the first time then have to redo because it failed an audit.
__________________________________________________________________
Part 1 - each of the following sections should be addressed in the SOP
|
A.
Purpose of the SOP |
The
SOP should start out with the purpose of the SOP. This is relatively
straight forward. The purpose of such an SOP is "To describe the process
by which you validate systems." Also include this definition,
"Validation insures that a system is suitable for its intended purpose
and that it meets the standards set by the FDA or EMEA." |
|
|
B.
Importance of creating a validation SOP |
It
is important because of the following reason: A regulated system helps in the collection or analysis of clinical data that is used to decide whether a drug, medical device or procedure is efficacious. A system that is error prone may distort the data thus making a decision on the effectiveness of the drug, device or process inaccurate. Always think what is the level of risk when this system is used. Any system that collects data during a clinical trial or is involved in the manufacture of a drug, vaccine, medical device is high risk and deserves an extensive validation.
|
|
|
C.
Audience |
State
who in the company should read and understand this SOP. List the job
titles of people and their department who should know this SOP. Don't
list people's names. A validation SOP is usually of importance to the Quality
Control (QC) staff, staff that created and maintains the system, project
managers, supervisors, company officers and statisticians. This list is
totally dependent on the way your company is structured. |
|
|
D.
References |
List
documents that you cite in this SOP. For example if you work in the
United States you have to cite 21 CFR 11 and/or ICH validation
documents. If you do not know what these documents are then look them
up on the FDA and EMEA web sites. Then reference any other corporate
SOP that you will cite in this validation SOP. At the end of writing
this SOP make sure you reference all appropriate documents, and check
that you do not reference a document that is not mentioned in the text of the
SOP. |
|
|
E.
Definitions |
List
acronyms and their definitions and any technical words that you feel need
further explanation. Define only acronyms and technical terms used in
the document. For example the following could be defined in a
validation SOP: validation, SOP, QC, test plan, etc..) |
|
|
F.
Validation Goals |
What
do you intend to achieve by following this SOP and what do you intend
to produce as output during a validation process
Remember you will need templates for all of these documents (with the exception of the test script) and the templates should be attached as amendments to the SOP (see Appendix A). |
|
__________________________________________________________________________________________
Part 2
Now we come to the part of the SOP where we describe the procedures in detail. When people write an SOP they tend to get carried away and attempt to create the perfect SOP. What happens is that they propose procedures and documentation so complex and cumbersome that they cannot be carried out. The result is that the actual validation process does not follow the SOP. The auditor sees this and has a wonderful time writing up all the places you did not follow your own SOP. Now you have to go back and re-write your SOP and then document to the FDA, EMEA or your client all the corrective actions you have taken. BE REALISTIC, REMEMBER ALL YOU WANT TO DO IS DOCUMENT THE SYSTEM AND THEN TEST THE SYSTEM TO MAKE SURE IT WORKS, that is the function of validation. Large pharmaceutical firms can write grandiose validation SOPs and can pay a contractor to carry them out, small pharmaceutical companies and CROs need to be realistic. Create a logical SOP, that when followed validates a system. Do not write something that you do not have the resources to carry out.
In this section you may notice I get carried away and start telling you not only what should be in the SOP, but give advice on how to write the validation package and carry out validation.
|
A.
Initiation of Validation |
This
is a document that states that the corporate officers and the QC manager have
agreed that validation of a system is warranted. It should also provide a
reason why it is warranted. This reasons could be the following
This can even be an e-mail to the QC department, that is initiated by the corporate officers or member of the information technology (IT) department stating that validation is needed. It can also be notes from a meeting that results in a decision that a system must be validated.
|
|
|
B.
The Requirements |
The
requirements is a document which organizes all the functions that the system
has to perform. This document is created for two reasons. First, to document
all tasks the users needs the system to perform and secondly, to communicate
these requirements to the system designers and programmers. The issues below should be dealt with in the SOP Mention that the document is divide into functional areas such as security, administration functions, user functions (data entry, data importation, data analysis, sampling) and report generation. In the actual requirements document for each of these areas provide a detailed breakdown of the functions. For example, under security you should address how the users logs on to the system by entering a username and password. You then address how the system handles the situation when a person continues to enter the wrong password. The SOP should mention the methods used to write the requirements. The requirements document should be done in a manner that is easy to modify. People will want to add new requirements at all phases of the development process. Use a spreadsheet or software created for documenting requirements. Mention in the SOP that you number the requirements so you can eventually map these requirements to the tests in the test script.
If you purchase a system (Commercial Off The Shelf, referred to as COTS) there are two approaches to documenting the requirements. In the SOP you can state COTS requirements may be dealt with as follows: 1. The requirements document created by the company that created the system will be requested. The company may or may not provide this documentation. In any case you must show evidence that you requested this document from the creator of the system. 2. Write your own requirements based on what you need the COTS software to do. The software purchased may do more then what is needed. In that case only document the requirements that you need. 3. If the manufacturer sends you their requirements document you may edited them down to reflect how you use the software By mentioning all these options in your SOP you are leaving many options opened to you in how you deal with requirements related to COTS software. The requirements document must be approved. This usually is the responsibility of the QC manager, the staff members who requested the software and others depending on corporate structure. Describe your approval process for the requirements. |
|
|
C.
The Design Document |
The
system analyst takes the requirement document and creates a design which is
used as a guide by the programmers. The programmers then write the
source code based on the design. Creation of a system design can be done
using many tools and techniques. This document can be a combination of
text, graphics (flow charts, relationship diagrams, etc..), table structures
and mock reports. This document should mention what software tools will
be used to create the system (i.e. Oracle, Delphi, C.net, Visual Basic.net,
etc..) The design document for a COTS system should be provided by the creator of the software. State this in your SOP. If the supplier of the software will not provide the design document you must show evidence that you requested this document. Most likely the manufacturer of COTS software will consider it proprietary and will not provide it to you. In the actual validation package mentioned when you requested the design document and the response you received from the manufacturer and when the response was received. The design document must be approved by QC, a representative of the IT department who will use the design to base their programming and corporate officers.
|
|
|
D.
The Validation Plan |
This
is the heart of the validation package it is going to describe the processes
used to prove that a system is doing what it is supposed to do. The
validation package should contain the following:
2. Risk assessment - This describes how critical it is that the system performs correctly. Since this system is involved in creating a portion of a submission to the FDA, European or Asian regulatory agency, the level of risk is high. The risk must be addressed, but in reality you would not validate a system that was unimportant, so the level of risk is always high. The risk is high because if the data is distorted in any way it could effect the decision whether or not the product is efficacious or safe. (See section 2 of the validation plan template - Appendix A). 3. Actions that will be carried out to validate the system a. Specify the actions - (i.e. developing requirements, writing test script, etc.) b. Who will perform the task (specify the type of person - software tester, programmer) Remember you need someone to write the requirements, plus people who will use the system will need to be interviewed in order to understand all the requirements needed. You will need a person to create a design, someone to program, someone to write the test script, someone to install the system in the test bed and make sure it is installed correctly, a software tester, a technical writer to write the user manual and a trainer to train people to use the system. If you have purchased a system fewer people are needed because there are fewer tasks to carry out. c. Estimated time to completion - A time line is of limited use. Mention in the SOP that this is only an estimate.
4. List all deliverables that will be produced a. Requirements b. Detailed systems design c. Validation Plan d. Installation Qualifications - How system was installed in the test bed and how success was determined e. Operational Qualifications/Performance Qualifications - The complete set of test scripts and result of each test.
Sometimes the operational qualifications will just involve making sure that all the primary modules are activated after the IQ. The more detailed testing is often referred to as performance qualifications (PQ). The OQ and PQ are most often divided up when the OQ is performed immediately after the IQ. The PQ then extensively tests all operations of the application and it will overlap to some extent with what was tested in the OQ.
When you create your own software there may be no need to create both a OQ and PQ, since you have been testing the software throughout its development, and should be confident that your IQ worked. This though is up to the development team and the QC department. For COTS software I would always create a separate OQ and PQ, because you will not be that familiar with the software and after the IQ is carried out you will want to know as soon as possible if the basic functions of the system are functional.
f. Requirements/Testing traceability matrix - Maps a specific requirement or requirements to a specific test script. g. Test Summary Report - Overview of the results of the testing h. Validation Summary - Overview of validation includes approvals i. Deviation Report, if necessary - What didn't go as planned and corrections made
5. How will these documents be controlled This falls under the domain of configuration management. Configuration management should be a separate SOP. Basically it consists of version control and naming conventions. For the validation plan you just want to mention how the documents will be stored. Also mention programming code control. Code control involves using a software tool or procedure so two people aren't changing the code at the same time. There are many software tools that can be purchased that can handle this job. Finally, if the version of the system changes what naming convention will be used. I recommend putting most of this in a separate configuration management SOP and just referring to this SOP. Also it is best to purchase a version control system that checks source code modules in and out. Version control software is also valuable for controlling documents.
6. Testing Approach In this section you will describe how your testing will be carried out. First give an overview of testing. Will it be done in a modular fashion? If you are testing after modifying the system will there be selective retesting of the system (regression testing). Describe how the test scripts will be written. How an error found during testing will be handle. How the error will be investigated and corrected and how the resulting re-testing will be done and tracked. If test data files need to be created describe how they will be created.
7. Quality Control Measures This section will list what steps the QC staff will take to insure all documents are written correctly and are approved. This should include a description of how QC staff will go over documents making sure all documents are created in the correct temporal order (i.e. test scripts should not be written before the requirements and design document). Here you are specifying how validation activities will be checked. The QC staff should be monitoring all documents as they are created so there are no surprises. One area that QC should pay particular attention to is dates. Make sure when someone signs and dates something the dates make sense. For example the date certified that a test was carried out should not be prior to the date the test script was created. Auditors are always on the look out for date problems.
8. Training that will be implemented If you are implementing a new system it will require training the users. This is also true even if the old system is undergoing extensive modification. Describe in the SOP how your company will decide what training is needed and how the training will be implemented. For example, if you have a staff trainer how will that person become familiar with the new system or modifications to an existing system. Once again do not make it so specific or complex that you cannot carry it out. For example, do not state that you will write a complete set of manuals when your company does not have any technical writers on the staff or the budget to carry out such a task.
9. Approvals This contains the dated signatures of the people responsible for approving the plan. These signatures are obtained before the plan is implemented. Their signatures indicate that the plan is sufficient and and by approving it you now have permission to carry it out. Declare in the SOP who should sign the document (there should be a submitter, reviewer(s), approvers).
|
|
|
E.
Test Summary Report |
The template in Appendix A can act as an outline for what should go into the Test Summary Report portion of the SOP. You are going to describe what you did to test the system. This should match what was stated in the validation plan in the Testing Approach section. Divide this part of the SOP into the following sections and in the SOP describe what each of these sections will be used for. 1. Testing environment: This is the document where you describe your testing set up. In the real validation package it will say something like, a COMPY 386 server was used as the test bed for the front end of the application, while a LapLink 360 server was used to support the database. The server was located at the StrongBad Corporate headquarters. Testing was carried out after the installation qualifications (IQ) were successfully carried out. This is about all the information you need. The IQ document will contain the detailed steps that were followed to actually install the system. 2. Testing documents created: This test summary report should just list the testing documents created. While this may not be the perfect place to discuss this I will describe what should go into each of these documents in a real validation package a. Installation Qualification: Steps to install application on test bed. In this document after each step a check box should be displayed indicating if the step was carried out successfully or unsuccessfully. The installer should initial each step indicating who carried out the step. At the bottom of the IQ document the installer should sign and date the document. In addition a verifier (person who attests that the installation was successful) should sign and date the document. If the system has a front end (user interface) and a backend (database) you should start by describing how the backend was installed and the steps used to make sure it was installed correctly, this is then followed by the steps used to install the front end.
b. Operational Qualification/Performance Qualification: This is the main component of the testing process. When validating a system I develop I do not create separate OQ and PQ scripts, however when validating a COTS system I usually create or use the manufactures OQ and a PQ (see Section D - 4e for a discussion of the OQ and PQ).
The OQ/PQ It is made up of testing instructions that tests each requirement contained in the requirements document. Each test should provide the tester with exact instructions, the expected results and a place to indicate if the test was successful or not. A tester should be able to use the OQ/PQ with little or no assistance. It is recommended that the test scripts should be numbered to correspond to the system requirements. The tester should sign and date the OQ/PQ after each functional test grouping. For example, after all testing involving security is completed the tester should sign and date the OQ/PQ. If a test fails and requires re-testing, a separate test script page should be inserted. If the test is passed that inserted page should be signed and dated. If you created your own software the OQ/PQ can take a long time to complete. The more complex the software the longer the OQ/PQ. Do not underestimate the time and cost of creating the OQ/PQ.
I recommend when buying a COTS product see if the manufacture provides or sells test scripts. This will save a great deal of time and expense. You may think you will save money by writing your own OQ/PQ instead of buying it, but you will be making an expensive mistake.
c. Traceability matrix: This is a spreadsheet or table that maps the requirements to the specific test scripts. This will serve as an auditor's guide. Just seeing that you have one will give the auditor confidence in your documentation. The table feature in Microsoft Word is an excellent tool for creating this matrix.
d. Test Summary report : This is the current document being described
3. Testing Result: This summarizes the results of the testing. If you reached this point of a real validation package things should have been successful. You can state that testing is completed and the system was shown to pass all tests in the OQ and/or PQ. Then reference the OQ and/or PQ.
4. Deviation from Testing Plan: If there was deviation from the testing plan mention them here. For example, sometimes the OQ tests may not be appropriate. The test script is found during testing to not actually test the requirement. In this case you do not check either of the two check boxes, instead you write NA for non-applicable. Then you document this in the Derivation section.
5. Certification of Completion of Testing: In this section you collect the signatures of individuals who certify that testing has been completed and that the Test Summary Report is acceptable. These signatures should include the QC director, a representative of the user group, person responsible for corporate software and a company officer.
|
|
|
F.
Validation Summary Report |
The validation summary report provides an overview of all the tasks that one carried out during the validation. Once again each of the sections listed below should be addressed in the SOP and describe the function of each section. 1. List the deliverables that were created (i.e. requirements design, IQ, OQ, etc..). Also mention where these documents are stored. For example the SOP should mention how you store these deliverables (i.e. all forms are stored in a locked file cabinet (preferably fireproof), and all the completed documents scanned and stored on a secure network directory (read only) Reference your SOP on storage of computer media. A word of warning validation is expensive and time consuming, it is not the time to be cheap scan your completed validation package with signatures and as a side note you should also scan all your SOPs). 2. COTS documentation. Here is where you write information about the company from which you purchased the software. Write the company name, address, phone number, fax number, e-mail address, web page, formal name of the software, serial number of software, version number, salesman's name, location of manuals that accompany the software and any other information you think could be useful. Remember this information is not for you but it is for the people who follow you. 3. Names of people and their jobs who participated in the validation. 4. Overall all result of validation. State that the validation was successful or if validation was stopped because the software proved to be faulty. 5. Problems encountered during validation. During the course of validation if something was not done or if an approval was not obtained, then document it and indicate why the plan was not followed and what was done to compensate for the deviation. Remember and auditor will not punish you if you admit a problem occurred and you did something to compensate for it, they will write you up if you pretended it did not happen. You can reference the Testing Summary Report if a deviation in testing is documented there. 6. Certification that validation has been carried out and the system can be made operational. This is a statement that validation has been completed and that the system can be made operational. The QC director, person responsible for corporate software, representative of the user group and a corporate officer signs. These signatures also designate the approval of the validation summary report.
|
|
|
G.
Training and Release of System:
|
These two areas may not be included in an actual validation package but they should be addressed or referenced in the validation SOP.
In your Validation SOP you should mention how you train users when you create or purchase a new system. You should specify who does the initial training (designer of software trains a group of sophisticated user who will then be responsible for training other users). Your company may have a separate training SOP that can be referenced here. An important question to address in this SOP or in your training SOP is how do you ascertain if a person is adequately trained and knows how to use the system. Do you create a test? Have a trained observer see how they operate the system and formally certify them. It is a good idea to have some documented evidence that the users have attained some degree of skill. This can be done by creating a certificate, a training log, etc. This is evidence of training that can be presented to an auditor.
Document the steps that will be taken to move the system from the test environment to its operational environment. A good procedure is to state you will follow the instructions used in the IQ document when moving the system to its operational environment. Then document this by completing a new IQ document with testing results and appropriate signatures to prove the move to the operational setting was successful. This can be included as a deliverable related to the Validation Summary Report.
|
|
|
F.
Retirement: |
The SOP should describe how a system should be retired. Retirement is usually started by the information technology (IT) department. A document is drawn up that states:
1. What system is being retired 2. Why it is being retired 3. Date of retirement 4. What if any system will replace this system 5. How and where the retired system will be stored and where (i.e. tape, in off site storage and on site in a secure room)
Have the responsible IT person sign and date the form and it should be approved by a QC representative. |
|
______________________________________________________________________________________
Last warnings
When you actually validate a system there can be friction between the QC department, the developers and the corporate officers.
The QC department should not be inflexible and remember that the validation process is created to prove the software works and the end product is a tested system. If there is a good reason not to follow the validation SOP, that is alright as long as you document it and it makes sense. Finally, get involved with what the programmers and the testers are doing don't sit back and wait until everything is done and then say it isn't good enough..
The developers must remember that if an audit occurs it is the QC staff who will be representing the system and the validation process. The QC staff have to be satisfied that the documents created will pass an audit because they have to defend them in front of an auditor. There is no worse feeling when an auditor asks for a document and you cannot provide it or you know it is weak.
Corporate officers are shocked at the cost of validation. However as I mentioned before, if an auditor feels procedures were not followed and writes a warning letter, the cost of correcting the omissions or errors will far exceed the cost of validation.
_______________________________________________________________________________________
If you have any questions please send e-mail to validate@plainsite.net , I am very good at telling people what to do.
Thank you
Val E. Datear PhD.
___Copy written 2006 _________________________________________________________________________
Appendix A
Selected templates:
These are draft templates that you can modify in any way. These blank templates should be attachments to your Validation SOP.
The Validation Plan
|
Part 1: |
||
|
Name of the system and a description of its function
|
||
|
Part 2: Risk associated with software that is being validated |
||
|
Describe the risk inherent in the use of this software
|
||
|
Section 3: Estimated completion time for validation |
||
|
Start Date: End Date: |
||
|
Tasks and estimated completion time:
|
||
|
Section 4: Participants and Tasks |
||
|
Participants |
Tasks for which participant is responsible: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Section 4: Deliverables |
||
|
Documentation: (List all documentation to be developed to support this system)
|
||
|
Software: (List main modules or components to be developed for this system)
|
||
|
Section 5: Configuration Management |
|
|
Code control method:
|
|
|
System documentation control method:
|
|
|
Section 6: Test Approach or Strategy |
|
|
|
|
|
Section 7: Quality Control/Quality Assurance |
|
|
List software quality activities that will be applied to this project: |
|
|
Section 8: Technical Training |
|
|
List all training needed by IT staff to implement software:
|
|
|
Section 9: Waivers |
|
|
The validation package will meet the intent of SOP P001, but will not be performed or documented exactly as specified in the SOP as it is anticipated that this SOP will be retired prior to completion of this project. |
|
|
Section 10: Signatures |
|
|
Submitter (System Lead): |
|
|
|
Signature Date |
|
QC Reviewer: |
|
|
|
Signature Date |
|
Approvers: |
|
|
|
Signature Date |
|
User Representative: |
|
|
|
Signature Date |
|
IT Director: |
|
|
|
Signature Date |
|
QC Director: |
|
|
|
Signature Date |
Test Summary Report
|
Section 1: Deliverables |
|
|
List all
deliverables that were created during the testing process
|
|
|
Section 2: Description of the Testing Environment |
|
|
Describe the hardware
and software of the testing environment (i.e. servers, operating system,
database used [Oracle, MS SQL server, My SQL, etc..])
|
|
|
Section 3: Test Results |
|
|
This should refer to the completed operational testing script.
|
|
|
Section 5: Appraisal of testing |
|
|
Was the testing successful
|
|
|
Section 6: Problems that arose during testing |
|
|
|
|
|
Section 7: Certification – Approval of testing activities |
|
|
|
|
|
QC Representative |
|
|
|
Signature Date |
|
QC Reviewer |
|
|
|
Signature Date |
|
Corporate Officer: |
|
|
|
Signature Date |
|
|
|
|
|
Signature Date |
Validation Summary Report
|
Section 1: Actual Tasks Timeline |
|
This section documents the tasks and the actual time it took to complete them
Start Date: End Date: Tasks Performed:
|
|
Section 2: Documents generated during validation process |
|
List all the documents generated during the validation process
|
|
Section 3: Vendor Information |
|
List the names, addresses, phone numbers, e-mail addresses of the manufacturers whose software was used to create the system. If it is a COTS product the information on the primary manufacturer should be entered here.
|
|
Section
4: Training |
|
|
|
Section 5: Actual Participants and tasks that were performed |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Section 6: Deviations from the Validation Plan |
|
|
|
|
|
Section 7: Certification for deployment |
|
|
Final certification verifying that all validation processes were carried out successfully |
|
|
QC Representative |
|
|
|
Signature Date |
|
QC Reviewer: |
|
|
|
Signature Date |
|
Corporate Officer |
|
|
|
Signature Date |
|
|
|
|
|
Signature Date |
Deviation Report Form
|
System :______________________ Date ____________________ Problem encountered: _____________________________________________________________________ _______________________________________________________________________________________ _____________________________________________________________________________ |
|
Will the requirement document need to be modified Y__ N___ What Deviation was carried out __________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________
|
|
Justification for carrying out the deviation _________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________
|
|
Approval:
Deviation
Approved? _____
YES _____NO Approval Signatures QC Director
_____________________________________________________ Date
___________ Programmer
_____________________________________________________ Date
___________ QC Reviewer
____________________________________________________ Date ___________
|
Documents generated during Validation (List how and where they are stored)
Validation
Plan
Requirements Document
Detailed Systems Design
Installation Qualification (IQ)
Operational Qualification (OQ)/Performance Qualifications (PQ)
Traceability Matrix
Test Summary
Validation Summary Report
Error Log
User Manual
Training Documentation
System Retirement Form