1 / 29

A Road Map to

A Road Map to. COTS Computer System Validation based on a HPLC, as example. Ulf Segerstéen Pharma Quality Europe AB. SARQ, 3rd of October, 2002. …. The Bar is being raised. PART 11 COMPLIANCE STD. NEW. CSV COMPLIANCE NEW STD. Validation of systems to ensure

zocha
Télécharger la présentation

A Road Map to

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Road Map to COTS Computer System Validation based on a HPLC, as example Ulf Segerstéen Pharma Quality Europe AB SARQ, 3rd of October, 2002

  2. …. The Bar is being raised PART 11 COMPLIANCE STD NEW CSV COMPLIANCE NEW STD Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records (§11.10(a)) COMPLIANCE CSV COMPLIANCE OLD STD NEW ER ER NO ER 21 CFR Part 11 effective Incipit requires ....

  3. CFR 21 P 11 GUIDANCE Computer system validation should be performed by persons other than those responsible for building the system. Two approaches to ensuring an objective review are: (1) Engaging a third party (2) dividing the work within an organization such that people who review the system (or a portion of the system) are not the same people who built it. Guidance Content: • GUIDANCE KEY ELEMENTS • System Requirements Specifications (5.1) • Documentation of Validation Activity (5.2) • Equipment Installation (5.3) • Dynamic Testing (5.4) • Static Verification Techniques (5.5) • Extent of Validation (5.6) • Independence of Review (5.7) • Change Control (5.8) • SPECIAL CONSIDERATIONS: COTS products and Internet Example of Guidance: Independence of Review

  4. COTS (Commercial Off-The Shelf) products CFR 21 P 11 GUIDANCE Commercial software used in electronic record keeping system subject to part 11 needs to be validated, just as programs written by end users need to validated (…) We do not consider commercial marketing alone to be sufficient proof of a program’s performance suitability (…) See 62 Federal Register 13430 at 1344-13445 March 20,1997 WRONG APPROACH SYSTEM IS A COMMERCIAL PACKAGE, WIDELY USED IT’S OK. NOT NEED TO BE VALIDATED RIGHT APPROACH END USER REQ SPECS SYSTEM IS A COMMERCIAL PACKAGE, WIDELY USED SW STRUCTURAL INTEGRITY FUNCTIONAL SW TESTING

  5. New Trend - Partnership by-Outsourcing Validation ActivitiesWhat’s in it for the Customer ? • Staying focused on his business - be more cost-effective. • Staying on top of the requirements - stay compliant rather than spending time solving regulatory issues. • Sharing the latest knowledge - don’t be active in all fields and save time for the core business. • Being prepared for what’s to come - get resources when needed, don’t let them be an added cost to the Products. • Being part of the solution NOT part of the problem - give theorganization confidence to handle changes and challenges. • Always having access to a Partner to discuss and solve issues with. What’s in it for the Partner ? • Client staying focused on his business makes easier for the Partner to support him. • Client staying updated on the requirements gives the Partner flexibility to act more proactively. • Sharing the latest knowledge makes the Client and the Partner understand each other, reducing misunderstandings and increasing efficiency. • Being prepared for what is to come helps the Partner to keep prices down and gives the Client more accurate budget control. • Being part of the solution, NOT part of the problem, helps both parties in solving and anticipating potential problems.

  6. The Lifecycle Activities for a COTS, using a Project perspective: SPECIFY TEST START UP SUPPORT & IMPROVE PLAN TO BEPROACTIVE CONTROL

  7. The Lifecycle Activities for a COTS, cont. SPECIFY TEST START UP URS (PROCESS) EVALUATION VALIDATION PLAN MASTER INDEX (MI) USER GUIDE SYSTEM ORG. & DOC’s VALIDATIONREPORT SOP’S (Approved) PROCESS Q FAT & SAT TEST PLAN DRAFT SOP’s

  8. CFR 21 P 11 GUIDANCE • It is important that your end user requirements specifications take into account • predicate rules • part 11 • and other needs unique to your system • that relate to ensuring • record authenticity • integrity • signer non-repudiation • and, when appropriate, confidentiality. The Lifecycle Activities for a COTS, cont. • User Requirement Specification based on: • the lab Process including the HPLC-equipment, HW-platform, SW-application, printer, expected filestorage and user interactions. • requirements for compliance to CFR 21 Part 11 (ER & ES) and other applicable GxP regulations • testable requirements SPECIFY URS (PROCESS) EVALUATION VALIDATION PLAN MASTER INDEX (MI)

  9. CFR 21 P 11 GUIDANCE End users should document their requirements specifications relative to part 11 requirements and other factors, as discussed above. Pharma Industry User Requirements Specifications Quality Assurance ______ System Owner _________ March, 2002 COTS End User Requirements Specifications Define what you need (all factors) Define what predicate rule needs Define what Part 11 needs

  10. The Lifecycle Activities for a COTS, cont. • Evaluation based on: • the CS fulfilling the Process that it is to be used within. • Risk Assessment Index, based on complexity of the CS and on the criticality for failure during the process.RISK MANAGEMENT=RISK APPROACH+RISK ACTIVITIES • the Suppliers expected role, process and responsibilities during the Project for developing + testing (FAT), installing and testing at the customers site (SAT), supporting the CS over time and license agreements. • fulfillment of compliance to CFR 21 Part 11 (ER & ES) and other valid GxP regulations • referenced other Pharmaceutical customers using the system. SPECIFY URS (PROCESS) EVALUATION VALIDATION PLAN MASTER INDEX (MI)

  11. The Lifecycle Activities for a COTS, cont. Evaluation of WHAT approach to take: GOLDEN RULE VALIDATION EFFORT SHOULD BE MAXIMUN FOR HIGH CRITICAL AND COMPLEX SYSTEMS. EFFORT MIGHT BE REDUCED THROUGH AUDITS IN CASE OF SW STANDARDS PROCESS CRITICALITY DATA COMPLEXITY SYSTEM CATEGORY

  12. High Software application whose features and functions have a direct impact on the quality, performance and efficacy of drug products Medium Software used for business process analysis, information and documentation systems that poses some business risk, or can have an indirect impact on drug products Low Packaged Software used for business purposes that poses no business risk Criticality Assessment

  13. Risk Assessment Evaluation The Risk Assessment Index (RAI) is a rationale to evaluate the criticality and complexity of computerized systems. • System Complexity is higher when system: • Performs detailed algorithm or calculations • Interfaces with other computerized systems • performs extensive data input checking • processes numerous types of transactions • requires extensive support to be maintained • involves a large number of users • GxP Criticality is an index of the impact of the system on pharmaceutical product or on raw data safety and traceability System Complexity RAI definition GxP Criticality (see next page)

  14. Risk Assessment Evaluation …that brings to RAI definition:

  15. RAI used for evaluating HOW to perform the Supplier Evaluation EVALUATION THROUGH REFERENCES RAI=0-2 RISKS EVALUATION THROUGH EXPERIENCES RAI=3-4 REQUEST FOR INFORMATION RAI=5-6 3RD PARTY AUDIT RAI=7-8 SPECIFIC FIRM AUDIT RAI=9 COSTS

  16. CFR 21 P 11 GUIDANCE When the end user cannot directly review the program source code or development documentation more extensive functional testing might be warranted than when such documentation is available to the user. COTS Functional Testing of SW dependent on Supplier Documentation available REDUCE VALIDATION EFFORT DEVELOPMENT DOCS

  17. The Lifecycle Activities for a COTS, cont. SPECIFY • Validation Plan based on: • Validation Strategy which is based on the Evaluation. • available Validation Methods, Tools and knowledge • a Validation Process that are documented as a matrix of all Validation Activities (VA), based on RAI that are expected to be executed for a HPLC (COTS). Rational given for VA’s that are not to be performed. Correspondent User roles in the Project and Supplier roles to these activities in the project are used in the same matrix. • statement for compliance to CFR 21 Part 11 (ER & ES) and other valid GxP regulations • required Supplier-, System Documentation and User Organization and SOPs for supporting and maintaining the CS. URS (PROCESS) EVALUATION VALIDATION PLAN MASTER INDEX (MI)

  18. Project • Documentation • User Requirements R E A L I Z E • Validation Documentation • Validation Plan • Validation Protocols and Records • Validation Report • Maintenance • Documentation • Registration • Support Agreements for HW and SW • SOP´s Master Index (MI) O P E R A T E Escrow Change Control Documents IQ Log User Documentation Periodic Review Validation Documentation Backup Log

  19. The Lifecycle Activities for a COTS, cont. SPECIFY TEST Prerequisites to move to Test phase: Reviewed and Approved URSApproved EVALUATION REPORT Reviewed and Approved VALIDATION PLAN Standard Index produced for all documents URS (PROCESS) EVALUATION VALIDATION PLAN MASTER INDEX (MI)

  20. CFR 21 P 11 GUIDANCE • Tests should include not only “normal or “expected” values, but also stress conditions. • Test conditions should extend to • boundary values, • unexpected data entries, • error conditions, • reasonable challenges, • branches, • and combinations of inputs. TESTING USR FSP SOPs VAL REPORT VAL PLAN TESTING IS THE KEYSTONE OF THE VALIDATION PROCESS... INDEPENDENCE FROM DEVELOPMENT

  21. The perfect path ….. STRUCTURAL TESTING This testing takes into account the internal mechanism of a system or component (white box testing). Structural testing should show that the software creator followed contemporary quality standards.This testing usually includes inspections of the program code and development documents. FUNCTIONAL TESTING This testing involves running the program under known conditions with defined inputs and documented outcome that can be compared to pre-defined expectations (“black box” testing) PROGRAM BUILD TESTING This testing is performed on units of modules, integrated units of code and the program as a whole. SYSTEM TEST FAT/ SAT OQ/PQ

  22. Life & Test Cycle Model: URS User Requirement Specification Performance/Process Qualification Risk Analysis Functional Specification Operation Qualification Risk Analysis Design Specification Installation Qualification Source Code / Source Code Testing SUPPLIER

  23. The Lifecycle Activities for a COTS, cont. TEST • Test Plan based on: • Validation Plan and RAI of the CS. • FAT, which would include review of Supplier Evaluation, Test, System & User documentation from the Supplier • SAT, which would include witness during IQ and OQ on site together with Supplier. These tests should normally include test for compliance to CFR 21 Part 11. • PROCESS QUALIFICATION, which would include performing the complete lab process as required by URS and User Guide, should also include CS Administration tests. • DRAFT SOPs could be in one document for this type of systems and should be available at PQ. PROCESS Q FAT & SAT TEST PLAN DRAFT SOP’s

  24. The Lifecycle Activities for a COTS, cont. TEST START UP Prerequisites to move to Start Up phase: Reviewed and Approved PROCESS Q based on DRAFT versions of the User Guide and SOP’sApproved FAT & SAT REPORT Reviewed and Approved TEST PLANFiled in the Master Index (MI) PROCESS Q FAT & SAT TEST PLAN DRAFT SOP’s

  25. The Lifecycle Activities for a COTS, END START UP START UP:THROUGH CS DECISION based on: USER GUIDE approved and Users trained SYSTEM ORGANISATION trained on CS and System Documentation available. VALIDATION REPORT, no remaining corrections, all documents in MI approved. (included in MI) USER GUIDE SYSTEM ORG. & DOC’s VALIDATIONREPORT SOP’S (Approved)

  26. Example of a Validation Tool to a COTS TOOL VALIDATION TOOL 1-CS Req. & SOP 2-Validation Plan & Report 3-Test Plan & Report 4-Validation Plan & Report REUSABLE APPENDIX • 1-CS Req. & SOP: • URS/FS/DS and user guide • Training • CS Security and authorization (incl. Backup and Contingency) • Maintenance • Change Control • Periodic Review • 2-VALIDATION P&R • Matrix with: • Activities incl. CFR 21 Part 11-declaration • Responsibility • Expected Output • 4-Validation Report • Reported Output • Deviations • Summary • Approval/Rejection • 2-Test Plan & Report • Ver. 1 • Matrix with: • Test case • Expected Result • 4-Test Plan & Report • Ver. 2 • Reported Result • Deviations/Re-test • Summary & Recommend.

  27. Effort Effort Save Effort Save Effort Save Infrastructure CriticalApplications Saving Effort by “Reusing” the Tool

  28. Finally:To be in Compliance means:Coordination(Policy & Standards) Cooperation(sharing knowledge & support) Capacity(make realistic Plans for big changes) Competence(get trained to gain competence) Consistency(use same measurements & tools)

  29. We envision to conveniently engineer innovative technology in order to synergistically facilitate value-added leadership skills to stay competitive in tomorrow's world Dilbert

More Related