List of Validation Documentation

gokeeffe · October 23, 2006, 7:36am

Does anyones want to add to this listing

What other documents can be used in a documentation lifecycle ?

Validation Master Plan
Validation Plan & Quality Planning
Risk Assessment
Quality Auditing
Compliance Plan
Quality Plan
Site Acceptance Test (SAT)
Factory Acceptance Test (FAT)
21 CFR Part 11 Assessment
Sotware Validation Risk Assessemnt Form
User Requirement Specification
Functional Design Specification
Installation Qualification
Operational Qualification
Performance Qualification
Equipment Installation Checklist
Intended Use & Base Risk Document
Tracability Matrix (Post URS/FDS & IQ/OQ)
Source Code Review
Final Validation Report

mgregor · November 2, 2006, 11:44pm

Nice post!

How about System Design Specification? (SDS)

Best regards,
Michael J. Gregor
Partner, ComplianceDoc

http://www.indexfda.com/

sandip · November 3, 2006, 3:33pm

How about Installation Record Document ?

gokeeffe · November 3, 2006, 5:48pm

What exactly is a installation record is it like an IQ

mgregor · November 4, 2006, 3:10am

Sandip/GoKeeffe,

I think there are two kinds of installation records, a install manual for SW or equipment and the installation qualification protocol.

Thoughts?

Michael

gokeeffe · November 6, 2006, 11:31am

So I guess it’s more like a Qualification than an IQ but then again some I’ve seen a number of Qualifications that resemble an IQ protocol.

All depends on the organisation in question I would imagine ?

DaveH · November 14, 2006, 11:47am

Don’t forget that in an Information Systems CSV environment there is much more, depending on the GAMP (if applicable to your company) category you are operating in. Including, in addition to the above mentioned message, but not limited to:

Invitiation To Tender (ITT)
Vendor Auditing & Selection
System Requirements
Software Development Plan
Unit Specs & Unit Tests
System Specs & System Tests
Technical Installation Plans & Reports (Developement/Test Environment)
Technical Installation Plans & Reports (Production/Go-Live Environemnt)
Deployment Plans
Change Management Plan
Configuration Management Plan
Document Management Plan
Training Plan
Project Support Plan (post ‘go-live’)
Service Agreements & Licenses
User SOPs
Incidident Management Plans
Bug/Issue Reports
Project Planning
WBS
Risk & Issue Management
IQ & OQ for development/test environment?
Configuration Verification
IQ for production/go-live environment
Post Implementation Review (PIR)

maryacton · November 14, 2006, 11:56am

Hi Dave,

I understand that you can have all of the headings that you mentioned, but when do you say stop!.

If you developed a document for each GAMP requirement it could take a long period of time before your application goes live.

I assume all of this will be decide in the risk assessment anyway, from my experience there seems to be standard set of documents that are always generated and documents such as Incident Management Plans and
Bug/Issue Reports are just fluff that is not really required.

Regards

DaveH · November 14, 2006, 12:22pm

I would agree…almost. My advice is to follow the GAMP categories and/or clients Policies and Procedures, certainly in Information Systems or Process Controls systems. In most cases it is quite resonable (with justification) to combine deliverables also.

I think the safe way to do all of this is to make sure you justify the approach you are taking within the Validation and/or Project Plan. However be very, very sure you are in compliance with the clients Policies and Procedures. I have been on FDA inspections (only as an observer) and have heard the dreaded statement/phrase from a ‘Systems Inspector’: “if you are not in compliance with your own company policies and procedires, how can you possibly be expect to be in compliance with the FDA CFR”!

meyert · December 4, 2006, 3:36pm

Dave,

Actually, the biggest thing I learned from working at a company under Consent Decree was exactly what your wrote. If you can’t follow your own procedures you surely do not follow GMPs.For computer validation it is “Do what is written in your plan” Not following plans or SOPs are what an auditor calls low lying fruit, why would an auditor break out the ladder to get the top most fruit when here is this juicy apple on this low branch. I have seen numerous companies kill themselves trying to meet “GAMP” in their plans. I say GAMP is a good start but typically unattainable, therefore the company must define their SDLC and follow.

Also, I sometimes will write a project plan that defines the entire project, and define what is required for GMP compliance and what is outside of the scope of the validation. That way if I don’t write a “project support plan,” an auditor can ding me for not being validated. With this approach I will also write a validation plan that details the validation. This is the document I give to an auditor.

DaveH · December 4, 2006, 4:18pm

I totally agree meyert.

Very interesting to read your comments on GAMP there also, and again I would totally agree with your project approach. GAMP is just a ‘reasonable guidance document’ and/or sub component of “proposed” GxP project deliverables; this must be remembered (particularly by the Project Manager) when mapping out a major project or you will die as a Project Manager/Organization.

PS. I am neither pro or anti GAMP. In my opinion it’s just a reference document; not a full life-cycle project management methodology with integrated SDLC.

meyert · December 7, 2006, 2:44pm

I also like to have a configuration specification for off the shelf systems. also a commissioning plan can be useful if you don’t specify in validation plan.

huigenghao · June 25, 2007, 12:35pm

Are you have a sample?

Ruth_Cunniffe · July 18, 2007, 7:30am

Also a ‘Regulatory Impact and Risk Criticality Assessment’, this document determines if you computerized system is;

GxP/ non GxP related,
Required to adhere to 21 CFR part 11 or not.

I would usually complete this document after reviewing the FS.

Ruth Cunniffe
Validation Engineer