Synertec Corporation Limited · ASX:SOP
Synertec — Technical Presentation (2003)
62 slides from Synertec's technical presentation, May 22, 2003
Slide 1: A Practical Guide to Validation
A Practical Guide to Validation David Paspa Systems Director Synertec Group © 2003 Synertec Group
Slide 2: Purpose
Introduction Purpose • Provide a simple, practical approach on how to validate a system. • Provide some useful ideas for both Clients and Suppliers.
Slide 3: Presentation Structure
Introduction Presentation Structure This presentation is broken into 3 parts: • Part I - Activity Based Definition of Terms • Part II - Practical Guide • Part III - Client/Supplier Relationship
Slide 4: Personal Background
Introduction Personal Background • Worked in Pharma/Biotech since 1990. • Worked on large and small projects. Large volume parenterals, veterinary products, APIs • Software Specification, Design, Development, Commissioning, Validation, Documentation. • Process Engineering, plant modeling, throughput
Slide 5: Part I – Activity Based Definition of Terms
Part I Part II Part III Part I – Activity Based Definition of Terms • Validation • Qualification • Define the Validation Activities
Slide 6: Validation is a Grey Area
Part I Part II Part III Validation is a Grey Area • Complex Industry. • Complex Regulations. • The word “Validation” is poorly understood. • Level of confidence => no right answer. • Many people have a different idea of what it is.
Slide 7: What is Validation?
Part I Part II Part III What is Validation? • “Provide documented evidence which provides a high degree of assurance… blah blah blah” • “It’s 9:00 am Monday, you have to validate ‘the system’. You have a pen, a piece of paper and a word processor. The boss wants results…. WHAT DO YOU DO?”
Slide 8: The Term “Validation”
Part I Part II Part III The Term “Validation” • It does not readily conjure up visions of useful, value adding activity. • It is seen as an expensive overhead which is not likely to result in negative consequences if corners are cut. • It is an evolving philosophy and has changed dramatically over t
Slide 9: The Term “Qualification”
Part I Part II Part III The Term “Qualification” • Some of the same comments regarding “Validation” can be applied to “Qualification”. • It does not readily conjure up visions of useful, value adding activity.
Slide 10: Qualification = Testing
Part I Part II Part III Qualification = Testing • Really means testing • Testing of systems against specified requirements. • So, a Qualified system is a TESTED system!
Slide 11: Testing Provides a Baseline
Part I Part II Part III Testing Provides a Baseline • Any test result is valid for any system provided the system has not changed since the test was performed. • Once the system has changed the test may or may not be valid. • Detection of a single, undocumented change which puts doubt on one test re
Slide 12: Manage Tested Systems
Part I Part II Part III Manage Tested Systems • Manage equipment. • Manage people. • Manage information. • Manage change. • Manage means... “to have effective control of”
Slide 13: Activity Based Definition
Part I Part II Part III Activity Based Definition • Testing • Management Validation Testing Management 50% 50%
Slide 14: Summary - Definitions
Part I Part II Part III Summary - Definitions • Qualification = TESTING • Validation = TESTING + MANAGEMENT • Usual activities for sound engineering and good project management.
Slide 15: Part II - Practical Guide
Part I Part II Part III Part II - Practical Guide • How to facilitate testing and raise confidence in the results • Management of Resources
Slide 16: Testing
Part I Part II Testing Part III Testing • What do you need to test? • Must have a specified requirement, otherwise it doesn’t make much sense.
Slide 17: Specification Documents
Part I Part II Testing Part III Specification Documents • If no requirement => can’t test If can’t test => no baseline If no baseline => can’t manage => requirements are fundamental to validation. • Historically IQ/OQ has often incorporated requirements and testing. • Manage requirements independent
Slide 18: Specification of Requirements
Part I Part II Testing Part III Specification of Requirements • The document is not the job. • Purpose is to convey information to the reader. • Simple, separate, short, stick to the facts, less is more (greater understanding and easier to test).
Slide 19: Types of Requirements
Part I Part II Testing Part III Types of Requirements • Priority 1 - Process Requirements (WHAT) (most important, not negotiable) • Priority 2 - Functional Requirements (WHAT) (less important, negotiable) • Priority 3 - Design Requirements (HOW) (least important, negotiable) • Many organisations can
Slide 20: Process Requirements
Part I Part II Testing Part III Process Requirements • WHAT the process requires. – Product Specification – Method of Manufacture – Quality – Throughput – Regulators – Process Flow Diagrams (PFDs). • Simple short document. • Sufficient for a Greenfield site if you could trust suppliers.
Slide 21: Functional Requirements
Part I Part II Testing Part III Functional Requirements • Conceptual Design. • Specify WHAT has to be done, not HOW to do it. • The Functional Specification identifies WHAT has to be done to implement the process requirements. – Piping and Instrumentation Diagrams (P&IDs). – The system shall provide
Slide 22: Design Requirements
Part I Part II Testing Part III Design Requirements • Structural Design. • Specify HOW the functional requirements will be implemented. – Hardware selection and installation details. – Software modularity and inter-communication. – I/O modules and allocation. • The Design Specification is crucial fo
Slide 23: Keep Documents Modular
Part I Part II Testing Part III Keep Documents Modular • Use “multiple buckets”. • Minimise the scope of work for a change. • V-Model benefits from modularity. • But…don’t repeat information!
Slide 24: Separate Live Information
Part I Part II Testing Part III Separate Live Information • Specifications must be kept up to date for the life of the system. • Some information is static, current only at the time of the project. • Project FS and DS should encompass project constraints.
Slide 25: Separate Information which you know will Change
Part I Part II Testing Part III Separate Information which you know will Change • Some components are unlikely to change unless there is a major design change or a major failure. • Pipes, tanks, wires, etc. • Some components are guaranteed to change due to normal operation, wear and improvement. • I
Slide 26: Time Dependency
Part I Part II Testing Part III Time Dependency • V-Model does not mention timing, but precedence of approval is inferred. • Fast-track projects demand early start. • Quality demands late start. • Compromise to manage business risk. • Document approval precedence is a regulatory requirement.
Slide 27: Legacy Systems
Part I Part II Testing Part III Legacy Systems • Legacy system is the ultimate in fast-tracking. System is already built and there is no documentation or validation in place. • How does the V-Model apply to legacy systems? • “Retrospective Validation” or “Revalidation”. • Implement the same strategy
Slide 28: Risk Assessment
Part I Part II Testing Part III Risk Assessment • Regulatory expectation to identify and focus on what is critical to process and product integrity. • Resources (time and cost) are limited to complete the work. • Useful management tool to minimise effort and maximise confidence.
Slide 29: Impact Assessment
Part I Part II Testing Part III Impact Assessment • Identify Direct Impact and Indirect Impact Systems. • For Direct Impact Systems identify non- critical sub-systems. • Minimise scope, maximise confidence. • ISPE Baseline Guide.
Slide 30: Requirements Traceability
Part I Part II Testing Part III Requirements Traceability • Provide a prospective mechanism to track each requirement from Process to Function to Design. • Not an add on but a useful tool to ensure all requirements have been addressed.
Slide 31: Requirement References
Part I Part II Testing Part III Requirement References • Requirement reference numbers used to provide useful requirements traceability down vertical part of V-Model.
Slide 32: RTM
Part I Part II Testing Part III RTM • Requirements Traceability Matrix provides an overview. • Not as useful if provided retrospectively. • Provide justification why lower level requirements do not exist. • Use it to verify completeness and contribute to testing the design (DR).
Slide 33: RTM Format
Part I Part II Testing Part III RTM Format • Complete close-out of requirements. UNRF JUST U10 U11 U12 U13 U14 U15 U16 U17 U18 U19 U1 U2 U3 U4 U5 U6 U7 U8 U9 UNRF JUST A A A F1 F2 F3 _ F4 _ F5 _ F6 _ _ _ _ _ F7 _ F8 _ F9 _ F10 _ F11 _ _ F12 _ F13 _ F14 _ F15 _ F16 _ F17 _ JUSTIFICATION LEGEND: A - E
Slide 34: Test Protocol
Part I Part II Testing Part III Test Protocol • Test Method • Expected Result • Observation • Test Result (Pass/Fail) • Signature and Date • Witness
Slide 35: Test Protocol Traceability
Part I Part II Testing Part III Test Protocol Traceability • Continue requirements traceability by using requirement reference number for traceability back along horizontal part of V-Model.
Slide 36: Summary - Testing
Part I Part II Testing Part III Summary - Testing • Requirements are fundamental. • Separate, modular documents for Process, Functional (WHAT) and Design (HOW) requirements. • Unique Requirement Reference numbers (1 per premise). • Prospective requirements traceability down “V” and across “V”.
Slide 37: Management
Part I Part II Management Part III Management • Equipment • People • Information • Change
Slide 38: Management of Equipment
Part I Part II Management Part III Management of Equipment • Configuration Management – Top down decomposition into Configuration Items (CI) – Testing handed over an audited Configuration Baseline – AS/NZS 3907:1996, AS4042-1992, AS4043-1992 • Procedures – Maintenance – Calibration – Operation – Bac
Slide 39: Management of People
Part I Part II Management Part III Management of People • Personnel – Job Description – Qualifications • Procedures – Training – Access • Manage the Way People Work – Take Responsibility
Slide 40: Management of Information
Part I Part II Management Part III Management of Information • Templates • Standards • Procedures • Filing (Electronic/Physical) – Don’t just throw things into a folder – Systematic approach, e.g. V • Consistent approach throughout the organisation.
Slide 41: Configuration Management
Part I Part II Management Part III Configuration Management • Manage the Configuration Baseline to keep track of: – Current equipment attributes (make, model, capacity) – Current values of configurable data (PID tuning parameters) – Current versions of software application programs and user programs
Slide 42: Management of Change
Part I Part II Management Part III Management of Change • Provide a procedural tracking system => Unique Reference Number • One system – Unique Reference Number – One Procedure – One Form (use attachments) – Less management overhead • Systems change over time (drift) • Track re-testing activities vi
Slide 43: Testing Changes
Part I Part II Management Part III Testing Changes • Changes must be re-tested. • Track re-testing activities via the Change Number to re-establish Tested Baseline.
Slide 44: Managing Management
Part I Part II Management Part III Managing Management • All management activities are inter-related… Equipment People Information Change …but don’t lose the baseline……
Slide 45: Client Document Management
Part I Part II Management Part III Client Document Management • The Goal : Inspection Readiness • Provide a consistent entry point into the system Validation Master Plan Multiple Systems First Point of Contact Project Strategy Project Execution Plan System Client Requirements Control Specification D
Slide 46: Management Tools
Part I Part II Management Part III Management Tools • Recognise that time, cost and quality are in competition. • Introduce simple tools to facilitate employee compliance with management requirements. – Document templates – Forms instead of documents – Filing systems – Non duplication of effort and
Slide 47: Summary - Management
Part I Part II Management Part III Summary - Management • Manage equipment, people, information and change. • Merge Quality with Activity – Change the way people work • Turn Liabilities into Assets – Organise and reduce
Slide 48: Part III - Client/Supplier Relationship
Part I Part II Part III Part III - Client/Supplier Relationship • Consequences of the Relationship • Responsibilities • The User Requirements Specification • Project V-Model
Slide 49: Generalisations
Part I Part II Part III Generalisations • Time ∝ ? Quality Quality – i.e. time is the enemy of quality • Confidence ∝ ? 1 Information – i.e. the more complex the project the less certain the outcome
Slide 50: Consequences of Relationship
Part I Part II Part III Consequences of Relationship • The actions of the client affect the supplier’s ability to maintain quality. • The actions of the supplier often don’t affect the client until much later during an audit when it is too late to do anything about it.
Slide 51: Client Responsibility
Part I Part II Part III Client Responsibility • Clearly specify requirements. • Supplier Audit. • Client has ultimate responsibility when confronting a regulatory auditor. • Prior to this, recognise that the client can influence time, cost and quality and thus the outcome of the audit. • wygiwyd -->
Slide 52: Supplier Responsibility
Part I Part II Part III Supplier Responsibility • Supplier should simply do what they said they would do (if only!). • Supplier Audit. • Obligation to provide all information that the client will need to pass the audit. – Functional and Design Specifications – Design Review Minutes – Completed Test
Slide 53: GAMP URS
Part I Part II Part III GAMP URS • Standard User Requirements Specification proposed by GAMP3 includes – Functions (calculations, modes of operation) – Data (definition, capacity, archive) – Interfaces (with users, I/O and other systems) – Environment (layout) – Constraints (timescales, compatibilit
Slide 54: V-Model Sympathetic URS
Part I Part II Part III V-Model Sympathetic URS • Covers – Process Requirements – Functional Constraints (not a blank sheet) – Design Constraints (not a blank sheet) – Commercial and Contractual – Time and Cost – etc. • Generally static information with the exception of the Process Requirements. • M
Slide 55: Full Project V-Model Diagram
Part I Part II Part III Full Project V-Model Diagram VP VR URS PQ RTM 1 DR1 FS OQ RTM 2 DR2 DS IQ Configuration Baseline BUILD
Slide 56: Engineering V-Model
Part I Part II Part III Engineering V-Model • Commissioning must be integrated into the model • ISPE Commissioning and Qualification Baseline Guide
Slide 57: Engineering V-Model
Part I Part II Part III Engineering V-Model VP VR URS PQ RTM 1 DR1 FS OQ OC RTM 2 DR2 DS IQ IC Configuration Baseline BUILD IC OC The Design Continuum
Slide 58: V-Model Roles & Responsibilities
Part I Part II Part III V-Model Roles & Responsibilities CLIENT CLIENT VP VR URS PQ RTM 1 ENGINEERING CONSTRUCTION ENGINEERING DR1 FS OQ OC RTM 2 DR2 DS IQ IC Configuration Baseline BUILD IC OC The Design Continuum
Slide 59: Facilitate Ongoing Management
Part I Part II Part III Facilitate Ongoing Management • i.e. “Validation” or “Validated” or “Maintaining the Validated State” VP VR URS PQ URS RTM 1 DR1 FS FS OQ RTM 2 DR2 DS IQ DS Configuration Baseline BUILD
Slide 60: Summary - Relationships
Part I Part II Part III Summary - Relationships • Client affects the Supplier who affects the Client who affects the Supplier…… • Work towards the common goal for the client to pass their audit. • The V Model URS is used for PQ => it should specify the Process! • Understand who will commission and h
Slide 61: Summary
Close Summary • Keep documents and their contents modular in accordance with the V-model. • Use requirement reference numbers for traceability throughout the complete lifecycle (encourages separation of each requirement). • Focus on minimising the amount of documentation and maximising access to inf
Slide 62: Thank You
Close Thank You If you would like a copy of this presentation visit our document library at: www.synertec.com.au www.synertecasia.com David Paspa Systems Director Synertec Group © 2003 Synertec Group