110 likes | 297 Views
Computerized Systems Validation - An old paradigm in a new world ? Uwe Trinks, Ph.D. PRISME Forum, Boston. Vendor Audit. Project Mgmt. Config & Validation. Installation ~ $ 1 Mio. 2%. 17%. 20%. SOP. 6%. Hardware (HW). 15%. Installation. 12%. Software (SW). 28%.
E N D
Computerized Systems Validation- An old paradigm in a new world ?Uwe Trinks, Ph.D.PRISME Forum, Boston
Vendor Audit Project Mgmt Config & Validation Installation ~ $ 1 Mio 2% 17% 20% SOP 6% Hardware (HW) 15% Installation 12% Software (SW) 28% Annual Operation ~ $ 500K Safety Systems Costs small Company
FDA Motto “In God we trust, all others need to bring data”
What the Regulator asked for…. • Definition • Establishing documented evidence which provides a high degree of assurance that a computerized system will consistently perform according to predetermined specifications and quality attributes • Predicate Rules • GCP/GLP/GMP (GxP) • 21 CFR • ICH E6 Good Clinical Practices (Part 310, 312, 314) • GLP and GMP (Part 58, 210, 211) • Quality System Practices (Part 820) • Guidance Documents • Available at http://www.fda.gov • FDA is concerned about the quality of DATA
Change Management What we made out of it…. Archiving Mandate Systems Decommission Risk Assessment User Requirements Systems Release Buy - Build Documentation Training Technical Specifications Validation Report Validation Plan (Protocol) IQ, OQ, PQ Programming Systems Test PQ Scripts Traceability Matrix
The GAMP Model • Designed with custom built Applications in mind • User Requirements collected independent of System • Translated into Functional Requirements • Translated into Design Specifications • Translated into Systems built or purchased • This is not, how systems are built or purchased today • User Requirements have no role in purchasing decision • Systems Functions either exist or don’t • System purchase follows more pragmatic parameters • System Configuration much more important and usually poorly tested
The problem • Reason for System Purchase • Already existing and not hated by users • Strategic vendor relationship • Trust in the vendors abilities • Installed base • Easier to get Consultants to help with implementations • Easier to hire Associates who already know the system • Someone else has figured out all the bugs • Impact on CSV • System is what it is – Defined Set of Functions • Retrofitting starts • Functions – Functional Requirements • Mapping to some obscure User Requirements • Mapping of Systems Installation Guide to Functional Design • Creating of Test Scripts for Functions • Already tested by the vendor • Already tested by numerous other companies
The problem (2) • Current CSV adds 6 months to any application implementation project • Substantial cost and time burden • Major hindrance for flexible IT planning • Prevents regular upgrades/software refresh’s • Does not add value • Repeating the same thing over and over and expecting a different result • Not suitable for any cloud computing • Manual process, cannot be easily automated • Needs to be repeated for any environment • Not suitable for the new world of handheld applications
Possible solutions • Move from a manual to an automated approach • All IQs and OQs should be automatically executed • Following standard protocol • Executed by the hosting company • Stored on the server and online auditable • Move from validation to certification • Similar to SAS 70, have external bodies audit and certify basic qualified infrastructure and application vendors • Do not repeat these tasks as a company • Works well in the banking system • Include the vendor testing into the picture • Do not repeat these tasks as a company • Vendors should publish their system and unit test script list • Vendors should publish audit results from an independent source (similar to SAS 70)
Our Speakers • John Wise • Review and of the CSV Questionnaire & discussion • Jonathan Helfgott, FDA • The Agency perspective • Rocco Timpano, Pfizer • The IT / QA Perspective • Sid Senroy, Biogen Idec • The Business / QA perspective • Glyn Williams, IDBS • The Technology Vendor / QA perspective