Validation Templates – The Starting Point of a Successful Validation Project
No matter how hard you try, if you don’t use templates, you will likely end up giving a sloppy, inconsistent look to all the various deliverables involved with a validation activity. Many of the deliverables on a validation project are “boiler-plate” and it doesn’t make much sense to recreate the wheel each time a new project commences.
Benefits
The benefits of using templates become obvious very quickly through a consistency between deliverable from one project to the next. Even when multiple people generate the deliverables, they all have the same look and feel. This consistency makes it easier for auditors to audit, and reviewers to review. It also gives them a warm fuzzy feeling to see consistent verbiage and approach between systems and departments. Using templates just looks professional and well thought out.
Another advantage of templates is that it provides a “gentle reminder” to document authors and project management, what exactly was needed for the validation effort. This prevents important deliverables like SOP’s, training documentation and Vendor Audits from becoming forgotten in the scramble of protocol development and execution.
Not Just for Protocols
You can use validation templates for everything, from SOP’s to Vendor Audits, Validation Plans, Protocols, and Final Reports to the verbiage you use when creating test scripts. The great advantage of the latter is that each tester will not be forced to come up with their own verbiage for say testing a Numeric field. Using a test script template allows multiple test-writers simultaneously to produce test scripts that are very consistent in format and technology. Essentially, the end result is a protocol that looks like it was generated by one person instead of many, which will look very professional.
If that isn’t enough reason to take the time to generate a test script template for your testers to use, then consider this: it takes a lot less time to cut-and-paste in a template, then tailor it to the field being tested, than it does for your test writers to struggle to come up with their own verbiage for every different field and field type.
Conclusion
Validation templates are a great way to add consistency to all your validation projects and activities, with the added advantage of reducing time spent on training. Validation templates should be generated by experienced people who understand exactly what the template needs to be used for, they should be written in a clear concise manner with no ambiguity throughout. There is little point in developing complex templates if nobody can understand how to use them.
Each template should be reviewed by the relevant stakeholders before approval takes place. What may make sense to a validation engineer may not make sense to the quality person reviewing the document.
Author
Tamara Follett has an M.S. in Computer Science and over 20 years experience in all aspects of cGxP Computer Validation. As an Independent Consultant serving the Pharmaceutical, Clinical Trials and Medical Device Industries, she developed and executed many large-scale computer validations and re-validations, identifying such critical deviations as data loss and data corruption prior to the system going into production.
She has generated and maintained Master Plans, Validation Plans/IQ/OQ/PQ/Final Reports/Deviation Logs/Deliverable Lists, and other project documentation such as procedures, work instructions and guidelines. She has developed comprehensive Life Cycle Documentation for numerous legacy and new systems, including Requirements, Specifications, Traceability Matrices, SOPs, Training/User Guides, and other SDLC deliverables, including: Needs Analysis, Vendor Gap Analysis, Risk Assessments, Disaster Recovery Plans, etc.
Ms. Follett has conducted numerous Compliance Audits, Quality Audits and 21 CFR Part 11 Audits. Considered to be a Subject Matter Expert in Computer Validation by Stat-A-Matrix, CSSC, and other validation industry leaders, she is a sought-after speaker and auditor.
I would wish to make only one comment on the creation and on-going use of Templates. The industry is fixated on APPROVING these templates in order to create a referenceable library of standard documents. Once a (sometimes self-appointed !) grouping produces their “masterpiece” Heaven and Earth may have to be moved to produce an auditor-friendly protocol.
By this I mean that it seems in some quarters inordinately difficult to persuade validation engineers that a template – YES even an approved one! – is still just a tool. It really is not the Holy Bible never to be modified or smartened up. For example, a very brief and realtively minor modification to an already qualified item does not necessarily HAVE to be a change control testing protocol consisting of the 47 pages which was initially required to fully qualify the equipment. Where 80% of the equipment’s functionalities will remain unaltered/unaffected by the proposed change, it really is OK to depart from creating a document where 80% of the test sheets carry the pre-printed and ingloriously incredible result “N/A”.
When as QA you have the audacity to point out following the QA review and comment phase that such draft documents are a little over-burdened with essentially blank pages when the testing proper consists only of perhaps 3 test sheets instead of the original 12 or 13, you are reminded that the document was created “using an approved template.” I consider this response to be evidence of intellectual laziness and hiding behind an shallow and self-defeating rule.
From an auditor’s perspective, there is nothing so annoying as leafing through page after useless page of Not Applicables – when you as the reader could have been informed on page 1 not only about what the protocol would contain (in the way of proof of success testing) but crucially WHAT it also WOULD NOT contain and WHY.
Whatever became of thinking through and owning the credibility of the document you are creating?
Is it really beyond simple comprehension that where 9 or 10 of the original test sheets are not impacted by the particular test being proposed, the template being used to create the document is ALLOWED TO BE modified to deliver a defendable and compliant document following the sequence outlined below?
The document author lists the test steps that will NOT be utilised as a consequence of the particular minor change to be performed defined by the associated Request for Change.
The author supports these test step absences with a clear and intelligible rationale in the doument’s introductory Purpose Section.
The nett result is we have a real live testing document that tells any reviewer WHY it exists;
it tells WHY the missing templated test steps have been omitted;
it DEFENDS their omission with a concise rationale; and finally, is only 12 very pertinent pages long instead of a proposed 47.
The integrity of the pursuit of delivering compliance is 100% respected – plus unnecessary and pointless paper consumption is avoided and the environment benefits. I see no losers.
Any thoughts?
I think that some people who do validation don’t really understand the “why” behind what they do, so they end up blindly following what they believe to be hard and fast rules. This is why we end up with ineffective validations, characterized by documents and activities that don’t necessarily make sense.
I believe that education is the solution to this problem, and I try to gently share my understanding of the concepts that underlie validation with anyone who shows a willingness to learn. Many people appreciate the extra time I take to help them, and this effort nearly always results in better performance of whatever validation related activity they perform.