Cv 1


Published on

computer system validation

Published in: Business, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Cv 1

  1. 1. Computer Validation Training Series Computer ValidationFundamentals Training Manual
  2. 2. Why do you need to be here?● As you use or support regulated computer systems, you may impact their validated state● This subject has been identified as a key concern by the highest levels of our company● We are expected to validate and control our important computer systems in accordance with GSK expectations● If important computer systems at your site operate poorly, it may reflect badly on all of GSK and cause a loss of customer confidence worldwide
  3. 3. After this training you should be able to….● Describe the background behind computer validation as it applies to GSK● Understand why GSK views this topic as a key business, safety, and regulatory benefit● Recognise the GSK Computer Validation Life Cycle and its major activities and deliverables● Explain the items included in the Computer System Validation Checklist● Know where to learn more about the GSK expectations for computer validation
  4. 4. Introduction● Computerisation is now dominating almost every aspect of our jobs at GSK● Computer validation has rapidly become a critical issue in GSK and throughout the rest of our industry● Many of our employees may not be aware that they routinely impact the validated state of computer systems● Computer validation is mostly important for business and safety reasons● However, many people first noticed computer validation because of regulatory scrutiny
  5. 5. Process Validation Roots● Process Validation began before Computer Validation● Regulators and the drug companies have both been focused on Process Validation for a long time● Process Validation terminology (e.g. IQ,OQ,PQ) and mindset carried over to Computer Validation
  6. 6. Is Computer Validation new?● No, it has been required for over 20 years● For many years, it was usually overlooked during regulatory inspections● During the last 5 years, it has quickly increased in importance to the regulators and drug companies● Many drug companies now see that there is high risk of severe punishment from regulators for not doing it properly● Everyone that uses, supports, buys, or develops regulated GSK computer systems must understand how their actions impact the validated state of those systems
  7. 7. What is a Computer System? In general, a combination of hardware, software, people, documents, inputs,processing, and outputs working together Inputs outputs Software Hardware Equipment Operating Procedures & Controlling System Documentation Controlled process People and Training
  8. 8. What Computer Systems do you use?● MRP/ERP system?● LIMS system?● Laboratory Instruments (e.g. Chromatography)?● Automated manufacturing or packaging equipment?● IT systems, including those supporting network and infrastructure?● Spreadsheets or databases?
  9. 9. Applicability?● Do you know how to identify whether a system you use requires validation?● Global Quality Guideline 1401A is our tool to sort these out● Do you know if the systems you sue have not been validated or were already validated?● Ask your local Computer Inspection Readiness representative or validation group. Your systems should be listed on a local system register that includes the validation status
  10. 10. Who plays a validation role?● Users play a key validation role in: ─starting the process for new or existing systems ─performing some major steps (e.g. Requirements) ─writing and following operating procedure ─maintaining the validated state while in use● Developers play a key role in many steps including: ─design, coding, testing, changes, support● Support groups (IT, IR, SCS, Infrastructure): ─maintain proper network environment ─troubleshooting and maintenance ─desktop and infrastructure control
  11. 11. Who plays a validation role?● QA and Validation ─author some major documents ─approve major documents that others write ─provide advice, training, auditing● Senior management for each group decides: ─which systems to buy or build ─how much resource to make available ─what risks are acceptable
  12. 12. How can computers systems be better than people doing the same tasks?● Computer systems that work properly...● are faster than people● make less mistakes than people● do not need sleep (24 hour operation is possible)● are less expensive than people (no salary)
  13. 13. How can computers systems be worse than people doing the same tasks?● Computer systems that work improperly...● cause people to lose time while they fix the errors● make much more serous mistakes than people● can stop all production or release or product● are far more expensive than people
  14. 14. Why can defects in computer systems be worse than other equipment problems?● When equipment breaks, there are typically obvious and immediate symptoms. Catastrophic results can often be avoided● Computer system defects can typically be very difficult to recognise and severe problems may result without being detected until well after the problem started● Drug companies, the airline industry, public utilities, nuclear power plants and other industries where quality is critical have seen very expensive consequences from improper computer system operation● Many of these consequences cost far more than the cost of Computer Vlidation
  15. 15. What is Computer Validation?● The ongoing process of establishing documented evidence which provides a high degree of assurance that a system will consistently perform according to its predetermined specifications and quality attributes● ongoing...- starts at initial concept, does not stop until retired● documented...- written testing● predetermined...- must document what we want at the start
  16. 16. Is it difficult?● It depends!● If you begin the process at the start, when the computer system is first considered for possible purchase or development, then it should be much easier● Lack of understanding of computer validation will make it more difficult, take more time, and result in more errors
  17. 17. Is it expensive?● It depends! Where do you draw the line between good business practice and required computer validation steps?● Many of these required computer validation steps are considered good business practice that many of us are taught during computer programming classes● If you compare it to the price of not validating, then the price is typically very low
  18. 18. Why Validation?● Business reasons● Safety reasons● Regulatory reasons
  19. 19. Cost to Fix When Problem found Cost to correctrequirements design code test implement
  20. 20. How can defects in your computer systems hurt the entire company?● The world is now much smaller with the use of the internet and mass media communications● Defects in your computer systems that cause harm to public may be rapidly communicated globally to all customers● Customers may then assume that they could be harmed by using our products made at any of our sites● This can reflect poorly on global product sales and stock values
  21. 21. Would you allow this surgicalcomputer system to be used on you?
  22. 22. The Regulatory Benefit?● Regulatory agencies around the world are rapidly increasing their scrutiny of computer systems ─In the first 5 months of 2001, there were 50% more computer validation findings than in all of 2000 (2nd highest category for From 483 observations)● GSK has come very close to severe penalties by the FDA for poor computer validation● Regulators have made it clear to us that they consider that problems at one site are an indication of conditions for the entire company
  23. 23. The GMP “Hook” to Computer Systems FDA:21 CFR 211.68● “ … equipment, including computers… that will perform a function satisfactorily… can be used in manufacturing, processing, packaging an holding of a a drug product.”● Requires “ … written program designed to assure proper performance.”● Requires “ appropriate controls shall be exercised over computer or related systems…” input/output accuracy check, backup file of data that is exact and complete● Requires written record of the program to be along with “ appropriate” validation data
  24. 24. The GMP “Hook” to Computer Systems MCA: Annex 11● “ Where a computerised system replaces a manual operation, there should be no resultant decrease in product quality or quality assurance”● “Where critical data are being entered manually … there should be additional check of accuracy of the record… This check may be done by a second operator or by validated electronic means”● “Before a system using a computer is brought into use, it should be thoroughly tested and confirmed as being capable of achieving the desired results”
  25. 25. There are also other regulatory agencies increasing attention on computer systems. These are just a few…
  26. 26. Regulatory Focus● We receive regular input on regulatory trends and expectations through many sources including…● Direct communication with the regulators● Representation in industry groups (e.g. GAMP, ISPE, PDA)● The FDA posts recent Warning Letters on their web site at warning.htm● “GMP Trends” publishes excerpts from Form 483 observations semi-monthly (● Other magazines, web sites, industry conferences, and more
  27. 27. Summary of Benefits● Computer systems now serve in critical roles in every aspect or our business● Because of the unique nature of computer systems, problems can be hard to detect in advance, but catastrophic● Poorly built systems can easily ─ halt production and product release ─ harm the public before we know of a defect ─ result in severe regulatory penalty● We cannot afford to ignore the need for ensuring that quality is built into our computer systems
  28. 28. Planning Planning Decommissioning Supplier Assessment Phases of Use Computer System Requirements Lifecycle Deployment Developmen Design and Code tCross-Phase Testing Activities (always)
  29. 29. Phases of the LifecycleReference Global Quality Guideline 1205 ●Planning ●Supplier Assessment ●Requirements ●Design and Code ●Development Testing ●Deployment ●Use ●Decommissioning ●Cross Phase-Activities
  30. 30. Planning Phase● Business Requirements ─high level, not product-specific ─can be used to make business case and select product ─required functions and constraints, ─enough detail to make compliance assessment● Compliance Assessment - is system GxP-related?● ERES Assessment - if GxP, assess based on GQG 1401A● Validation Planning ─defines standards to maintain quality during life of system ─key roles and responsibilities ─deliverables, rationale for approach
  31. 31. Supplier Assessment Phase● Compare supplier’s validation activities/deliverables with ours● Information used to determine activities needed by GSK where supplier is deficient● Validation Plan should state whether supplier audit is needed and when it will be done
  32. 32. User-Supplier Relationship Primary Responsibility Primary Responsibility for Specification for Testing Testing of the URSUser User Requirements Performance Specification Qualification User More Supplier involvement for custom More User involvement for custom Functional Testing of the Operation systems, less for packaged systems, less for packaged Specification Functional Specification Qualification Testing of the Design Installation Specification Qualification Design Specification Build System Design Unit Testing Specification SupplierSupplier Requirement Specification System Testing
  33. 33. Requirements Phase● Business Requirements are further developed to make the User Requirements Specifications (URS)● URS details what the system should do, but not how● Categorise level of importance- must, should, could
  34. 34. Computer System require more detailed specifications...
  35. 35. User Requirements Specification Requirements Phase● Requirements traceable to Functional Specifications and testing● Unambiguous, clear, concise● Testable and measurable● Typically written and approved by end-user● Basis for system acceptance testing● Should be approved before the design review
  36. 36. Functional Specification Design and Code Phase● The highest level design document responding directly to the User Requirements Specification● All system inputs, outputs, and interfaces● All functions and performance requirements● Error definition and handling● Ranges, limits, defaults● Safety considerations
  37. 37. Design Specification Design and Code Phase● Defines how the system should meet the requirements, including…● Architecture AND interfaces● All functions● Data processing and integrity● Security● Backup, archive, and restoration● disaster recovery● Data definition
  38. 38. Design Review Design and Code Phase● Activity performed to verify that all deliverables from Requirements and Design Phases are produced and…● are clear and concise● are complete, current, and traceable● electronic record and signatures addressed● are testable● show system fit for purpose
  39. 39. Coding and Configuration Design and Code Phase● Design Review should be complete before starting● Should be performed in accordance with written Programming Standards● Programming Standards should define appropriate rules for writing source code (e.g. dead code, structure, naming)● Example of Dead Code: Line 5: GOTO Line7; Line 6: Add 5 to all input variables; Line 7: Add 3 to all input variables; For this example, it should not possible for Line 6 t execute during actual system operation
  40. 40. Code and Configuration Review Design and Code Phase● Should be completed before formal testing● Verify code complies with Programming Standards● Check to ensure all pre-defined system specifications are addressed● Check for coding errors
  41. 41. Development Testing Phase
  42. 42. Testing at Multiple Levels Development Testing Phase ‘White Box’ *● Unit Testing/Structural Testing out● Low level in ‘Black Box’ *● System & Acceptance testing● Functional Testing● Higher level in out Manual Calculation * -Unofficial term used for explanation of concept
  43. 43. Test Plan Development Testing Phase● Define and justify the how the system will be tested and how much● Address how tests are traceable to specifications● Testing approach should address —normal operation —entire design range, boundaries, stress —failure modes, including power failure● Should be approved before testing starts
  44. 44. Test Case Development Testing Phase●Lists the test objective●Traceable to specifications●Lists test pre-requisites●Reproducible test steps●Clear acceptance criteria
  45. 45. Test Results Development Testing Phase● Record all raw data and derived results● Ticks, ‘ok’, ‘yes/no’, ‘Pass/Fail’ or similar are not valid results● Record a ‘Pass/Fail’ conclusion of whether results met acceptance criteria● Signature and date of test performer● Signature and date of test result approver● References to incident log for failures
  46. 46. Test Report Development Testing Phase● Used to… ═collate test result documentation ═conclude each phase of testing ═authorise subsequent testing phases● Summarises the testing outcome, addresses test failures
  47. 47. Deployment Phase● Data Load● Operational and Support Plans (e.g. SOP, training, service contracts, security, support processes)● Installation Qualification (IQ) - verifies installed in accordance with specifications and diagnostics checks performed
  48. 48. Deployment Phase● Operational Qualification (OQ) -user acceptance testing of base functionality under normal and stress conditions● System Release - can use in live environment before PQ● Performance Qualification (PQ) - verify OK while in actual use● Validation Report - summarise all activities, address deviations, provide conclusion
  49. 49. Use Phase● Implementation of Operational and Support Plans● Dial-in Support Services - be very careful if you allow this● Upgrades and fixes - manage through change control● Periodic Reviews - verify still in a validated state● Revalidation as required
  50. 50. Archive and Decommission Phase● Occurs at end of system life● Store records to ensure compliance with rules for electronic records and record retention
  51. 51. Cross Phase Activities●Requirements Traceability●Change Control●Configuration Management●Incident Management●Documentation Management●Training
  52. 52. Validation Planning● “ A documented plan exists for validation this system”● Sample Regulatory Observation No original planning documents included in the validation materials for the programs● “ This plan includes the deliverables and activities that were to result from the validation effort”● Sample Regulatory Observation ‘The procedure calls for the same individual who writes/revises the program to validate the program’● “The supplier of this system has been audited (report available)”● “ A system description or overview is available”
  53. 53. Functional Requirements (document in the User Requirements Specification)● “ Functional Requirements (or equivalent named document) exist for this system”● “The Functional Requirements identifies all functions that the system must perform”● “The Functional Requirements are approved using a signature”● “The Functional Requirements are updated for each system functional change”● “The Functional Requirements include enough detail to allow objective test measurement”● Sample Regulatory Observation ‘The procedure discusses discrepancies in decimal places between the computer and manual results and …” significant values”. There is no definition of “significant values”’
  54. 54. Functional Requirements (document in the User Requirements Specification)● “ Either the Functional Requirements or Design Specifications provide a system overview”● “Function Requirement are traceable to corresponding design elements”● “ Function Requirement are traceable to corresponding test elements”
  55. 55. Summary/Release Documentation● “ The system was not released prior to completion of the activities defined in the validation plan”● “ Version numbers are used to identify each component of the computer system installed for use and it’s current supportive documentation”● Sample Regulatory Observation ‘Inadequate software version control’● “ All required approval signatures were obtained prior to release of the system”● Sample Regulatory Observation ‘Inconsistencies in the review of the validation documents’● “A summary of the validation documents and activities for this computer system is available”● “ The system was released into production in accordance with a SOP”● Sample Regulatory Observation ‘There were no written requirements/specifiactions and validation protocol SOP at the time of validation’
  56. 56. System Maintenance and Operation● “ Change were tested prior to placing the change into production use”● “ Enhancements and modifications to computerised systems and associated documentation re implemented under change control and configuration management that maintains version history of computer components”● “ Changes were approved prior to placing the change into production use”● Sample Regulatory Observation ‘Inconsistencies in the review of the validation documents’● “ The site’s change control documentation fully describes proposed or actual changes”● “There is a SOP defining how users are to interact with the system to perform their jobs”
  57. 57. System Maintenance and Operation● “ All system users have been trained on the system operation SOP”● “The need for possible regression testing was addressed in the change control documentation”● “ There is a written Disaster Recovery Plan that will restore operation of this system”● “ Documented testing of the Disaster Recovery Plan has been performed”● “ Changes have a documented evaluation of whether a complete system re- validation is warranted”● “ The site can provide a list of authorised users and their security access profile”● “ There is evidence that access is terminated for transferred or terminated employees”● “ There is a documented process and criteria to revoke system access”
  58. 58. Electronic Records/Electronic Signatures (ERES)● “A written ER/ES compliance assessment, suitable for presentation to an investigator, is available for this system”● “ The application has an automatic, electronic audit trail to record changes to electronic records”● “ Authorised deletions of electronic records are only performed with an appropriate audit trail”● This completes the Computer System Validation Self Inspection Checklist, but there are many other critical computer validation points on the other Self Inspection Checklists that are not specific to individual systems
  59. 59. What about Legacy System?● Your site may have systems that are not validated or that don’t meet today’s regulatory expectations● These systems must be validated to comply with GSK policy on computer validation (Global Quality Policy 1205)● GQP 1205 does not allow retrospective validation as an acceptable substitute for prospective validation● For systems that are in use without validation, retrospective validation should be done as a prospective
  60. 60. Scalability● Many deliverables in the computer validation life cycle may be combined into the same document or made smaller● This scalability is dependent on the size, complexity, intended use, and risks associated with the computer system● However, some deliverables cannot be combined because of their intended role and timing in the life cycle● For example, Business Requirements can often be combined with the User Requirements Specification, but Requirements and Testing cannot be combined
  61. 61. Can this be done more than one way?● Yes!● GQG 1205 describes how several key areas of intended use for computer systems may be validated differently ═Laboratory systems ═Control systems ═Desktop applications ═IT systems ═IT infrastructure ═Software tools
  62. 62. Should this always be done the same way?● No!● You probably don’t have the resource to use a “one-size-fits-all” approach to computer validation● Regulatory agencies have made it clear that they do not insist on a “one-size -fits- all” approach● Attempting to validate spreadsheets using the same method as for a MRP system may be wasting resource that could be better applied to fixing compliance gaps
  63. 63. Is this a one-time effort?● Validation does not end when a system is put into use● When systems are changed, the validation deliverables may need to be updated● As your site’s priorities and resources change, more work may be required to improve the compliance of system● As regulatory expectations for computer validation change, more validation activities are required● Significant resource is always needed on permanent basis to maintain the validated state of systems already in use
  64. 64. Popular Misconceptions?● “ We bought it from a vendor…” so we can get by with very little for validation● The vendor supplies a validation package - that’s all we need● “ Validation can be done at the end - just be fore turnover● The Validation Department approved it - there shouldn’t be any bugs● Computer Validation is slowing down this project● We can’t afford to perform Computer Validation● The Regulatory Agencies will not look at our Computer Validation● Testing is Validation
  65. 65. What does success look like?● Many of our manufacturing sites have not yet experienced a computer system inspection, but will soon● Without having first-hand knowledge of what it takes to succeed during a computer system inspection, many sites need help● Global Computer Validation can help by providing training, coaching, consultation, and examples
  66. 66. Challenges● Staff that are not trained or experienced in performing computer validation and don’t know what they don’t know● Lack of resource-people, time, money● Resources are not always allocated based on a complete understanding of the challenges faced in achieving compliance in computer validation● Specific regulatory expectations can be hard to define, since much of them are not written directly into regulations
  67. 67. What should we target first?● We must comply with commitments made by GSK to the regulators● We must avoid deficiencies that have repeatedly been the source of citations to GSK and other pharmaceutical companies● These are all defined in the Computer Inspection Readiness Self Inspection Checklists● We must also follow all of Gsk policy, but start with these checklists
  68. 68. Priorities● Computer validation is only one of many high priorities that your site or group faces● Your site or group is responsible for determining the proper balance of resource and risk for each of these challenges● The Computer Inspection Readiness (CIR) Training outlines the prioritisation strategies that you should use for addressing your computer systems● The CIR Self Inspection Checklists indicate numerical weighting of many relevant topics
  69. 69. Risk Management● Management staff for your site or group will decide their tolerance level for risk in each major category of issues● Poor computer validation can be very expensive. These risks are business, safety, and regulatory related● This guideline is called “ Computerised Systems - Management of Risk to Product Quality and the Application of Interim Measures”
  70. 70. Quick Wins● Improving the “perception of control” of your computer systems can reduce your regulatory risk somewhat without adding resource● Strategies for increasing this perception of control are described in the Computer Inspection Readiness Training, offered by Global Computer Validation● Interim measures can be applied for short-term mitigation of risk (e.g. procedural, administrative workarounds)● Incremental improvement starting with the most critical computer systems (MRP, LIMS,CDS, Process Control) is recommended
  71. 71. Quick Review of the Big Picture Planning Decommissioning Supplier Assessment Phases of Use Computer System Lifecycle Requirements Deployment Developmen Design and Code tCross-Phase Testing Activities (always)
  72. 72. Summary● Computer validation has become very high visibility in our industry and at GSK● There is very real business and safety benefit, in addition to concerns with regulatory agencies● GSK has a guideline that clearly describes the entire computer validation life cycle and GSK expectations● The Computer System Self Inspection Checklists, published on the web, give excellent focus to the most critical issues Finale