Validation Sop

STANDARD OPERATING PROCEDURE Number: GEN.149

Page 1 of 8 pages

Revision Number: 009

Title: Computer System Validation Effective Date: 01/05/2009

WRITTEN BY:

/ Author

/ Date

PURPOSE To describe the methods for conducting and documenting computer system validation.

SCOPE This procedure applies to computer systems developed or purchased by that require validation due to its possible impact on 21 CFR Part 11, procedures, specifications, processes, product and/or financial data. This procedure does not apply to the following: •

Software used as a component, part, or accessory of a medical device (e.g. Galileo, Echo);

•

Software that is itself a medical device (e.g., blood establishment software);

•

Software used in the production of a device (e.g., programmable logic controllers in manufacturing equipment, GMP Environmental Monitoring system);

RESPONSIBILITIES Application Owner is responsible for ensuring that the FRS, DDS and CSVP documentation are written/updated and approved prior to implementation of the software for its intended use, and that Segregation of Duties and/or SOD deficiency mitigation requirements are defined therein appropriately. They are responsible for ensuring the planning, performance and completion of all computer validation/testing activities. IS Department is responsible for the reviewing and approving the FRS, DDS and CSVP documentation, and ensuring that Segregation of Duties requirements are defined by the Application Owner and met prior to implementation of new software applications. Department Directors(s) or designee where the computer system will operate are responsible for ensuring that all validations are completed prior to implementation of the system for its intended use. Regulatory Affairs is responsible for ensuring that the documentation and validation process complies with regulatory compliance requirements. Quality or designee is responsible for ensuring that the documentation and validation process complies with Quality System requirements.

GEN.100F3

GEN.100 Rev.08/25/2008

STANDARD OPERATING PROCEDURE Number: GEN.149

Page 2 of 8 pages

Revision Number: 009

Document Control is responsible for the notification for Biennial review and for the maintenance of computer system validation records.

DEFINITIONS Application Owner: The individual who owns or uses a specific function of the computer application requiring validation. The application owner is the primary contact for the application. This may be the primary user or the manager of the team responsible for using the application. Segregation of Duties (SOD): Desired process state achieved when no single individual has control over two or more phases of a transaction or operation, so that deliberate fraud is more difficult to commit because it requires collusion of two or more parties. When duties cannot be adequately separated, procedural controls should be put in place to reduce the risk. The following are examples of procedural controls that may be used to mitigate issues related to segregation of duties: 1. Audit trails that provide information on who initiated a transaction, the time of day and date of entry, the type of entry, what fields of information it contained, and what files it updated. 2. Independent verification processes utilized by end-users to increase the level of confidence that functions executed successfully. 3. Exception reports handled at supervisory level, supported by evidence noting that exceptions are handled properly and in a timely fashion. 4. Manual or automated transaction logs maintained to record all system activity. 5. Supervisory reviews 6. Independent reviews Biennial Review: Document review to be conducted every two years. COTS: Commercial off the shelf software. System: An integrated collection of computer equipment/hardware, software applications, and communications networks. Application/Software: A stored program within a hardware computer system designed to be used as a tool to perform a process or task. Module: A functional unit within an application, which performs a specific procedural task. Detailed Design Specifications (DDS): Specifications that document how a system is to be built. It typically includes application and module structure, data structure, input/output formats, etc.

GEN.100F3

GEN.100 Rev.08/25/2008

STANDARD OPERATING PROCEDURE Number: GEN.149

Page 3 of 8 pages

Revision Number: 009

Functional Requirements or Functional Requirements Specifications (FRS): Requirements that specify the normal or characteristic actions a computer system must be capable of performing. Hardware: Physical equipment that performs logical operations and is controlled by a stored program. Major Update: When brand new functionality or designs are introduced into the system. Minor Update: When a modification to an existing functionality or design is introduced into the system. Sunsetting: Terminology used for discontinuation of an information system or specifically a computer system. Validation or Testing: Confirmation by examination and provision of objective evidence that the particular requirements implemented in the software for a specific intended use can be consistently fulfilled.

FORMS Functional Requirement Specification Template Detailed Design Specification Template Computer System Validation Protocol Post-Implementation / Pre-“Go Live” Check Log

GEN.149F1 GEN.149F2 GEN.149F3 GEN.149F4

PROCEDURE 1. GENERAL 1.1. Complete validation testing of COTS is sometimes not practical due to both cost and unavailability due to proprietary concerns of some software. COTS software should be validated specifically for its intended use and only to an appropriate level of validation. Risk Management, of course, is the major input to determining an appropriate level of validation (See Appendix 1). 1.2. Non-configurable COTS software is software that can be used as-is after installation. Examples are antivirus, operating system and word processor software. In the case of non-configurable COTS software, “Testing of output” may be sufficient. This means that if the software can be tested by functional testing to confirm each and every software specification and requirement, those validation tests may be sufficient without the need of further testing. 1.3. Computer systems undergoing validation must have a Part 11 Assessment completed according to GEN.164. 1.4. Any significant change to a validated computer system must be documented using Computer Validation Change Management (GEN.147). Any insignificant change will follow Information Services Work Request (GEN.824). Note that “significant” and “insignificant” changes are defined in GEN.147.

2. COMPUTER SYSTEM DOCUMENTATION: 2.1. Computer system validation (CSV) documentation consists of an FRS, DDS and Computer System validation Protocol (CSVP). 2.2. Identification Numbers (CSV ID) are assigned and tracked by Document Control.

GEN.100F3

GEN.100 Rev.08/25/2008

STANDARD OPERATING PROCEDURE Number: GEN.149

Page 4 of 8 pages

Revision Number: 009

2.3. The CSV ID is unique for each validation protocol. The format used is comprised of the following: 2-digit year, 2-digit month, and a 3-digit sequential number. The following examples illustrate the format: CSV ID: 0412001 (2004, December, first CSV of the month) CSV ID: 0412010 (2004, December, tenth CSV of the month) 3. System Function and Design Specifications 3.1. There can be flexibility in this documentation due to the many different computer systems and their available documentation. Some applications are purchased with pre-written specifications and/or validations. 3.2. Functional Requirements Specifications (FRS) 3.2.1. The Author should follow whenever applicable the FRS Template Form (GEN.149F1) to identify and describe the user and functional specifications. Functional specifications for COTS are sometimes unavailable due to proprietary requirements of the developer and therefore cannot be documented. Or, a complete list of Functional requirements from the developer may already be available without need of further additional documentation. In these cases the Author MUST document in the FRS any deviations from the template (E.g. FRS documentation from the designer can be attached or a reasoning for “no” specifications stated in the appropriate sections of the FRS). 3.2.2.The FRS document is to describe the required system functionality, user requirements, general assumptions/dependencies, and the segregation of duties and/or SOD deficiency mitigation requirements. 3.2.3.Part of the Functional Requirements is Risk Management (See Appendix I). In the FRS determine if the requirements have an impact on procedures, specifications, processes, product, or safe use of the product and document actions necessary to mitigate or eliminate potential risks, if applicable. 3.2.4. The FRS should be updated to reflect the evolving functional needs (See Section 6). 3.3. Detailed Design Specifications (DDS) 3.3.1.The Author should follow whenever applicable the DDS Template Form (GEN.149F2) to describe and identify all design requirements. Design specifications for COTS are sometimes unavailable due to proprietary requirements of the developer and therefore cannot be documented. Or, a complete list of design requirements from the developer may already be available without need of further additional documentation. In these cases the Author MUST document in the DDS any deviations from the template (E.g. Design documentation from the designer can be attached or a reasoning for “no” specifications stated in the appropriate sections of the DDS). 3.3.2.The DDS documents how a system is to be built. It typically includes system or application structure, algorithms, control logic, data structures, data set (file) use information, input/output formats, interface descriptions. Vendor supplied user/installation manuals; internally developed documentation, externally developed documentation or a combination of sources may address these specifications. For simple systems they may be combined into a single document for manageability. Application descriptions should include sufficient information to provide a basis for system maintenance and development of user-acceptance testing criteria. 3.3.3.The DDS should be updated to reflect the evolving design changes (See Section 6).

GEN.100F3

GEN.100 Rev.08/25/2008

STANDARD OPERATING PROCEDURE Number: GEN.149

Page 5 of 8 pages

Revision Number: 009

4. Computer System Validation Protocol (CSVP) 4.1. All Validation testing and SOD setup MUST be completed and approved prior to implementation of the of the computer system for its intended use. NOTE: utilizes its daily backup procedures to serve as its rollback plan for all Applications. The backup and restore procedures as documented in INS. 131 ensures that programs and data can be reversed if data becomes corrupt due to implementation of a change. 4.2. The CSVP (GEN.149F3) is a testing protocol written by the application owner with support from the IS department and validation department. The CSVP is used to document validation testing activities by the individual testing the computer system (E.g. the application owner). It is used to identify, describe and trace test cases to be performed during the validation. Three of the most important components of the CSVP are the testing approach, the test cases and deviation reporting/resolution. Test cases serve as a traceability listing where each function listed in the functional requirements specification is tested. 4.3. Computer System Validation Protocol (GEN.149F3) should be followed whenever applicable to perform and document validation testing. Some means of traceability should be created in correlating all the test cases to their requirements. This can be accomplished within the Validation protocol or a separate traceability matrix. 4.4. The Author, Application Owner, Information Services, Quality and Regulatory Affairs must Pre- and PostApprove the CSVP to ensure that it has adequately documented the test evidence of a system’s suitability for its intended use. 5. Post-Implementation / Pre-“Go Live” Check Log 5.1. Prior to the “Go-Live” in production verify that the Production environment matches the test environment and that SOD is setup in production as approved by application owners. Use the Post-Implementation / Pre-“Go Live” Check Log GEN.149F4. This Log is used to verify items that can be used to prove matching between the two environments and is approved by Information Services and the Application Owner. If no validation environment exists and this form is not applicable it may be disregarded. 6. UPDATING/VERSIONING/ Biennial REVIEW OF AN FRS AND DDS 6.1. The FRS, DDS and CSVP will reference in their documentation the CSV# to allow for ease of crossreferencing. 6.2. A Versioning Number for changes to the FRS and DDS will be unique for each update of the documents. The format used is comprised of a 2-digit, single decimal place sequential number system starting at version . The following examples illustrate the format: Major Updates will change to the next whole number: 1.0, 2.0, 3.0, etc. Minor Updates will keep the first digit and change the second: 3.0, 3.1, 3.2, etc. Note: If Major and Minor Updates occur at the same time, the versioning will move to the next sequential Major update “whole” number. 6.3. The FRS and DDS are approved (at a minimum) by the Author, Application Owner and IS. 6.4. Testing documents should list the FRS/DDS with the Version number being tested to allow for ease of cross-referencing. 6.5. The FRS, DDS and CSVP documentation should be maintained together with all subsequent versions

GEN.100F3

GEN.100 Rev.08/25/2008

STANDARD OPERATING PROCEDURE Number: GEN.149

Page 6 of 8 pages

Revision Number: 009

being added as revisions occur. 6.6. All completed CSV documentation is filed in Document Control. 7. Biennial Review of the FRS and DDS 7.1. The Application / Document owner will review their systems FRS and DDS biennially and update the documents if any changes (additions, deletions and/or modifications) from the previous review or date of Final-Approval of the last version. If an update is required, the Application / Document Owner will follow section 6 to update the documentation. 7.2. A complete review should account for the identification of any CSCRs (GEN.147F1) that may have occurred since the previous update and those changes that the CSCR made to the systems functionality or design. 7.3. If an update is found not to be required and the document version is still correct with the applications functionality and design in production, then a memo will be written and added to the validation packet that after review of the documentation, no updating is required. 7.4. Document Control will maintain a listing of the CSVs and will notify Application Owners when review is due. 7.5. It is the responsibility of the Application Owner to perform the review and update the documentation or add the memo to file, if required. 7.6. If the system is discontinued, the review is discontinued.

RECORD RETENTION Computer System Validation documentation is retained per the requirements stated within GEN.113.

REFERENCES Document and Record Control/Storage Computer System Change Management Non-Product Software Validation Assessment Information Services Work Request Electronic Record Retention

GEN.113 GEN.147 GEN.164 GEN.824 INS.131

APPENDIX Appendix I: General Guide to Perform Risk Management Risk Management determines if the change has an impact on procedures, specifications, processes, product, and/or safety. Documented risk management may be necessary to mitigate or eliminate potential risks, if applicable. This documentation within the FRS is to be completed by the application owner with the support of the IS department. 1.0 Risk Analysis

GEN.100F3

GEN.100 Rev.08/25/2008

STANDARD OPERATING PROCEDURE Number: GEN.149

Page 7 of 8 pages

Revision Number: 009

1.1 In the FRS define Intended Use or Purpose of the system. 1.2 Under the Risk Management Section compile a list of foreseeable risks associated with a requirement. 1.3 For each identified risk estimate the severity, likelihood and controllability using available information or data.

FRS Requirement No.

Risk Severity Severity Impact Weight Minor 1 Moderate 2 Significant 3 Very significant 4 Disastrous 5

Risk Likelihood Occurrence Weight Unlikely 1 Somewhat likely 2 Possible 3 Very possible 4 Almost certain 5

1 2 3 4 5

Effectiveness Check

Risk Total

Control

Likelihood

Mitigation Severity

Risk

Control Manageability Weight Easily avoidable Very controllable Moderately controllable Difficult to control Uncontrollable

2.0 Risk Evaluation 2.1 For each identified risk, decide whether the estimated risk(s) is so low that risk mitigation need not be pursued. If the combined (“Risk Total”) risk numbers from Severity, Likelihood and Control added together are equal to or greater than 10, risk mitigation is required to be performed. If less than 10, the risk mediation need not be pursued; however, justification for that decision must still be documented in the mitigation section of the risk chart. 3.0 Risk Control 3.1 When risk mitigation is required, perform the process to control the risk(s) so that the residual risk(s) associated with each risk is judged acceptable. Non-exclusive examples of types of risk mitigation are as follows: 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6

GEN.100F3

Process modification Procedural modification Product modification Increased testing Decreased testing Avoidance

GEN.100 Rev.08/25/2008

STANDARD OPERATING PROCEDURE Number: GEN.149

Page 8 of 8 pages

Revision Number: 009

3.2 The implementation and effectiveness of the risk control measures shall be verified by the application owner, with the support of the IS department and documented in the effectiveness check area of the risk chart. To verify a mitigation activity is effective, obtain objective evidence that the activity is doing what it was required to accomplish.

GEN.100F3

GEN.100 Rev.08/25/2008