Computer System Validation and, Good Documentation Practices for GxP Systems

1. Computer System Validation and,Good Documentation Practices for GxP Systems

2. Agenda • What is CFR Part 11 • What is Computer Systems Validation • What is good documentation • Background and purpose • Authoring of documents • Changes and Modifications • Objective Evidence • Deficiencies Documentation • GxP Documentation

3. What is CFR Part 11 • It’s the FDA’s final rule on Electronic Records and Electronic Signatures • Defines requirement underwhich electronic records and signatures are equal to paper • Requires regulated industries to implement controls including audits, system validation, electronic signatures and documentation of software and systems involved in the processing of data

4. What is Computer System Validation (CSV) • Computerized System Validation is an ongoing process which involves the evaluation and documentation of all components of a system during its lifecycle phases to ensure compliance with the authorized user requirements. • Computerized System Validation requires establishing documented evidence which provides a high degree of assurance that a system meets its predefined specifications, performs and will continue to perform accurately and reliably, and is secure from unauthorized or accidental change. • The major reasons for validating computerized systems are: • Ethics: CSV helps by ensuring that systems function as intended thereby minimizing risk to patients and their families. • Control: CSV provides a framework for management control of complex computerized systems. • Compliance: CSV is a regulatory requirement.

5. More About CSV • Responsibilities: The ultimate responsibility for validating a computerized system rests with the identified Business Owner. The Quality Assurance (QA) group must monitor, audit and authorize the validation. • Policy Statement : All organizations will have a CSV Policy. • All new systems within the scope of the CSV policy must be in a validated state prior to their operational use. Existing systems within the scope of this policy, if not yet validated, must be retrospectively validated. • All systems within the scope of this policy must be maintained in a validated state. • CSV Requirements: All CSV activities must fully comply with this Policy and it is strongly recommended that such activities should follow the concepts in the Corporate CSV Guidelines. • Corporate CSV guideline will provide the principles for performing system validations

6. GxP Systems Documentation Deliverables • Vendor Audits • GxP Assessments • Part 11 Assessments • Master Validation Plan • User and Functional requirements • Risk Assessments • Technical Architecture documents • Installation Qualifications • Operational Qualifications • Performance Qualifications • UAT • Qualification reports • User Operating Procedures (SOPs) • System Administration Procedures • End User Training • Traceability Matrix • Validation Summary Report • System Release Memo

7. WBS For a Validated System

8. Documentation Descriptions • The Project Charter: This describes the reason for the project and defines the scope of the project. This deliverable provides the framework for the validation project and justifies its business need. • Validation Plan: This document represents one of the key deliverables and is one of the most important documents in a CSV project. It outlines the strategy and remediation strategy for new and legacy systems. The main objective of this document is to achieve full compliance with corporate computer system validation strategy. It is this document that provides the details regarding the subsequent documentation that will be required for validating the computer system. This plan also describes the methodology to be used for obtaining compliance for the system at hand, providing guidance to the validation team in terms of understanding and executing validation activities. • Functional Specification, Design Specification and User Requirements: These documents specify requirements needed for a system, from both a user and hardware perspective .The most important of these is the Functional Specification document which details all the functional needs required for an application. This document is where the specifics of the computer application are documented and acts as a living document which is updated if any further changes are made to the application. This document defines what the expected pre-determined specifications of the computer application should be. • Test Plan: The test plan defines in detail the effort that will be put into the testing of the application. It clearly specifies all the stages of testing that a computer system will go through and provides a scope of the amount of testing which will be conducted for a system.

9. Documentation Descriptions • Installation Qualifications: Defines the qualifications for the installation procedures which will be required for the implementation of the software. Here all the required installations are qualified, which means that the installation will follow a defined process and will meet the requirements of the organization and more specifically the defined project needs. Installation qualification will test the Design Specifications. • Operational Qualifications: Describes how the application will function and whether it will meet its described functions. Operational Qualification tests all the features described in the Functional Specification. Specific test scripts are written for each of the features in the FRS and the application’s capability is verified. This verification is to ensure that the application will meet the needs of the organization. • Performance Qualification: Represents a series of documents which ensure that the application will meet the production standards defined by the organization and detailed in the user requirements. Here again a series of production scripts are written and the application is tested to ensure that it is capable of meeting the desired results. It is only after the formal execution of the production scripts and the formal signing of the Performance Qualifications that a computer application can be moved into production.. • Summary Reports: These reports summarize the results of the executed qualification documents. Here the summarized information recaps all the qualification standards used and what the results and deviations for IQ, OQ and PQ qualifications are. • Deviations Reports: This is a set of documents that formally logs any deviations from the expected results during the formal Operational and Performance qualifications. To

10. Introduction of GDP • Good documentation practices must adhere to the following GxP (x= Manufacturing, Laboratory and Clinical): • Authoring • Changing • Maintaining • Distributing Of documents related to Validation and Qualification documents

11. Background and Purpose • Must ensure that documents can reliably serve as proof of actions and results • Must clearly define the documentation of the practices • Must provide clear instructions on how to create, approve, scan and store documents • All employees have to be trained in the practices • Applies to all validated environments • Must be unambiguous in the content, • Must state the scope clearly of each document defined • Each document must have a unique identifier

12. Authoring of Documents • Author needs to assign a unique identifier for the document • Author is responsible for tracking the document throughout its development and approval life cycle • Author will distribute the document to appropriate reviewers • Author will address all the questions and comments addressed by the reviewers • Author will ensure all approvers have signed the document • Author will be responsible for the version control of the document • Author will ensure the document is properly filed • Author will be responsible for any changes made to a final approved document and reversion the document • Author will be responsible for capturing all the edit history of the document

13. Document Changes and Modifications to Final versions • Good documentation practices must follow the following for document changes and modifications. These are: • Must maintain revision history section showing full name of person who made changes • Specific description of the changes must be written clearly • Date of when changes were made must be indicated • Version number of the document to which changes were made must be documented • All comments and suggestion cannot be addressed in the final version, are allowed only in draft versions of the document • Final version changes must be done within the change control standards of the organization • Each document must contain a official signature log containing the printed name, signature and initials of each person modifying the document • Initialing of the document must be kept consistent • Predating and posting changes is not allowed

14. Handwritten modifications to documents • Handwritten entries to GxP related documents are acceptable but can only be done in the following manner • Must use permanent blue or black ink • Use of correction fluid and correction tape is not permitted • Must record the date and must be consistent to the with the international format ddMMyyyy • Must clearly indicate the change made • Must include the signature and name of the person making the modification • Must update the official signature log of the document • A fax or printed PDF of the official signature must be attached to the original record • Must inform the author of the changes • Following steps must be adhered to when a hand correction is made • Draw a single line through the area of correction • Enter the corrections • Include an explanation for the change • Initial and date the change

15. Objective Evidence • Where Objective Evidence is needed the following are the practices necessary • Must be collected, paginated and dated by the tester • Predating and post dating are not permitted • Evidence must contain page number, total number of pages and testing steps • For systems must produce screen shots of the evidence • Must show completion of the test • Must mark any deviation from expected results clearly • Must mark successful test steps clearly • Must be able to repeat the steps tests are successful

16. Deficiencies documentation • All deficiencies of in testing must be accompanied by a Deficiency Report. (DRF) • Must be filled for each deficiency encountered • Deficiencies occur when expected result does not match the actual results • DRF should also be created when there are missing approval on testing procedures • A log of all deficiency reports need to be maintained