COMPUTER SYSTEM VALIDATION AND,

GOOD DOCUMENTATION PRACTICES FOR

GXP SYSTEMS
 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
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
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.
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
 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

WBS FOR A VALIDATED SYSTEM
WBS CSV
IMPLEMENTATION

VALIDATION PRODUCTION
PLANNING PHASE
PHASE PHASE

DEFINITION / INFRASTRUCTURE SOFTWARE SOP VALIDATION

DATA MIGRATION
ANALYSIS PHASE QUALIFICATION QUALIFICATIONS COMPLETION SUMMARY
REPORT

USER HARDWARE DATA MAPPING APPLICATION

PERFORMANCE
REQUIREMENTS QUALIFICATION MATRIX INSTALLATION
QUALIFICATION RELEASE
QUALIFICATION
VALIDATED
SYSTEM TO
FUNCTIONAL AND SOFTWARE DATA MIGRATION USERS
DESIGN QUALIFICATION PLAN APPLICATION
SPECIFICATIONS OPERATIONAL TRACEABILITY
QUALIFICATION MATRIX

OPERATIONAL DATA MIGRATION

VALIDATION PLAN
QUALIFICATION QUALIFICATION

INFRASTRUCTURE INFRASTRUCTURE DATA MIGRATION

QUALIFICATION QUALIFICATION SUMMARY
TEST PLAN SUMMARY REPORT REPORT

TEST PLAN

SOP INITIATION
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.
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
 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
 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
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
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
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
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
 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