System Validation



Title: System Validation

SOP

|Document number |ADMIT-004-00 |Author |Y Claeys |

|Version number |1.0 |Reviewer |J Smedley |

|Superseded Version |Draft |Review Date |16-Aug-2012 |

|Effective date |10-JAN-2013 |Status |Final |

Table of contents

General information

Responsibilities

Definitions and abbreviations

Method

Attachments and forms for completion

References to other SOPs

Revision

Approval and distribution

References

1 General information

1.1 Aim and application

• The aim of this procedure is to define all key aspects involved in Data Validation. It is not the objective to specify a step by step working method, but merely to create a frame in which the working instruction can be developed.

• This procedure is applicable to any projects especially in medical research area, study or clinical trial where you or or want to be sure that the developed database, software application, hardware,… works conform researchers expectations and conform the protocol

1.2 Legislation and standards

• For clinical trials the minimum standards is based on ICH-GCP ()

o Good Clinical Practice (GCP) is an international ethical and scientific quality standard for designing, conducting, recording and reporting trials that involve the participation of human subjects.

o Compliance with this standard provides public assurance that the rights, safety and well-being of trial subjects are protected and that the clinical trial data are credible.

• For electronic data capture 21 CFR Part 11 defines the criteria under which electronic records and electronic signatures are considered to be trustworthy, reliable and equivalent to paper records

• For non-clinical trials the minimum standards are decided on project by project basis, on a risk-based approach, in agreement with the Head of , Project Leader at and the responsible Data Manager, while keeping the general objective of safeguarding the data from source document until database lock

• If local legislation requires additional standards for DM, then these need to be adopted.

2 Roles and Responsibilities

|Roles |Responsibility |

|Head of the Data Management Unit |Approve only relevant documentation during the Validation Process |

|Data Manager |Draft the paper documentation (URS, FS) for system validation |

|System Developer |Draft the paper documentation (IQ, OQ, PQ, VR) for system validation |

| |Supervise and approve testing done by a system reviewer/tester |

| |Ensures reprogramming and retesting in case of deviations |

| |Make sure that the system goes live only after all System Validation |

| |Documents are signed |

|System Reviewer |Follows the test script on the OQ or IQ |

|Project Leader or delegate |approve all documentation during the Validation Process |

|Quality Assurance |approve all documentation during the Validation Process |

3 Definitions and abbreviations

Definitions

• Validation: Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined

Abbreviations

• URS : User Requirement Specifications

• FS : Functional Specifications

• OQ : Operation Qualification

• IQ : Installation Qualification

• PQ : Performance Qualification

• VR : Validation Report

• DM : Data Management

• eCRF : electronic Case Report Form

• GCP : Good Clinical Practice

• ICH : International Conference on Harmonisation

• QA : Quality Assurance

4 Method

System Validation process needs common phase as below:

4.1 User Requirement Specification

The URS document is a high level description of the system explaining why it is required and what is required of it. It includes the background, key objectives and benefits, main functions and interfaces, applicable GCP requirements, and other applicable regulations as basis to chose a proper system or sofware

• The URS is created based on the protocol. If the protocol doesn’t have all the required information these must be obtained actively (email, meetings, teleconference,..) and validated thru the URS document

• The URS should be created before the system or software is chosen

• Submit the URS for review and approval.

Template

Data Management Checklist (see General DM SOP) or use a separate URS Template

4.2 Functional Specification

The FS document defines the required system functions, modes of operation behaviour. It is aimed to find a consensus regarding the functionalities of the chosen software

• Create and approve the FS before actual programming

• List and describe all functionalities that the product must support, such as but not limited to: automatic edit checks, input masks, specify enabling of question variables, calculations, derivation, access requirements and safety levels, backup,… data dictionary may be used as template to model the functionalities in relation to the question variables

• The Project Leader approves these functionalities which will be the basis of system development

Template

Data Dictionary (see eCRF Design SOP)

4.3 Installation Qualification

The IQ provide documentary evidence that the system has been built and installed correctly and that all required supporting services are available and connected correctly

• The system developer needs to record the information for each module/component, add-ons, supporting files and utilities, and compare to the developer’s/manufacturer’s specifications.

• Verify URS and record any deviations to the specifications.

• Test scripts should not be executed by the system developer

• Closely examine (and document) the installation process and any log created.

• Prepare a Deviation Report including the justification of acceptance and impact on the function.

• Prepare an Installation Qualification Report, this should include amongst others:

o date completed; observations made; problems encountered; completeness of information collected; summary of deviation report; results of any tests; sample data if appropriate; location of original data; other information relevant to the study; and conclusions on the validity of the installation.

• The tester and System developer approve the IQ

Template

IQ Template and Retest Template

4.4 Operation Qualification

The OQ determines that the system operates according to URS and FS, and to record all relevant information and data to demonstrate it functions as expected.

• The system developer creates a test script that proves the well functioning of al functional specifications (see FS)

• Test scripts should not be executed by the system developer

• Closely examine (and document) the operation process and any log created.

• Prepare a Deviation Report including the justification of acceptance and impact on the function.

• Prepare an Operation Qualification Report, this should include amongst others:

o date completed; observations made; problems encountered; completeness of information collected; summary of deviation report; results of any tests; sample data if appropriate; location of original data; other information relevant to the study; and conclusions on the validity of the installation.

• The tester and System developer approve the OQ

Template

OQ Template and Retest Template

4.5 Performance Qualification

The PQ determines that the system performs as intended with real data and tests intended to demonstrate satisfactory performance over the full range of expected operating conditions. These tests are preferably done by the site personnel (end user) if possible

• PQ should be done only after OQ is completed

• The system developer defines the required test scripts to be performed (eg number of cases to be entered in the system during a certain period of time).

• Test scripts should not be executed by the system developer

• Closely examine (and document) the operation process and any log created.

• Prepare a Deviation Report including the justification of acceptance and impact on the function.

• Prepare an Operation Qualification Report, this should include amongst others:

o date completed; observations made; problems encountered; completeness of information collected; summary of deviation report; results of any tests; sample data if appropriate; location of original data; other information relevant to the study; and conclusions on the validity of the installation.

• The tester and System developer approve the OQ

Template

PQ Template

4.6 Validation Report

The Validation Report binds all Validation documents described in this SOP and summarizes any deviations that were not solved during the process

• Any limitations use the system live can be explained

• In case PQ was not possible in test environment and thus not done on validating the VR, this must be explained and PQ added to the VR binder at later stage.

Template

VR Template

4.7 Maintenance

All changes to the system during live conditions must be validated. Depending on the impact on the system this System Validation SOP is required (for high risk interventions such as CRf structural changes) or a change control form (minor changes in system with no or limited risk to the system such as adding edit checks)

• Change Control Form only needs signed approval for release by the System developer + an independent tester

• Keep a log form of all changes done once a system operates in live conditions

Template

Change Control Template

5 Attachments and forms for completion

Data Management Checklist (see General DM SOP) or use a separate URS Template

Data Dictionary (see SOP eCRF design)

Attachment 1: URS Template

Attachment 2: IQ Template and Retest Template

Attachment 3: OQ Template and Retest Template

Attachment 4: PQ Template

Attachment 5: VR Template

Attachment 6: Change Control Template

6 References to other SOPs

This SOPs focuses on System Validation and should be read together with

- General DM SOP

- SOP for data collection Tool_paper CRF design

- SOP for DB_eCRF design

7 Revision

|Version | Changes with respect to the previous published version |

|Draft |Draft version presented at 2011 Data Management Workshop at ITM, Antwerp by Paritosh|

| |Malaviya and Yves Claeys |

|Version 1.0 |Changes made based on discussion at the 2011 Workshop and subsequent harmonization |

| |process by Yves Claeys (ITM) and James Smedley (LSTM) |

8 Approval and distribution

| |Name and function |

|Initiated by: |Name and function of the person(s) initiating the document |

|Approved by: |Name and function of the person(s) approving the document |

|Manual distribution: |Indicate the manual distribution of the document. |

| |E.g. ‘No manual distribution.’ |

| |E.g. ‘1 copy available in the laboratory.’ |

| |Preferably no hard copies of this document should be made unless absolutely |

| |necessary. |

9 References

• Practical Guide to Clinical Data Management (Susanne Prokscha – second edition)

• Standard Operating Procedure 16 Case Report Forms (CRF) Review: January 2008 Version 1.0 Warwick Clinical Trials Unit (Online reference)

• Wikipedia for modeling definitions (online reference)

• Computer System Validation - It’s More Than Just Testing (online reference: )

• Leveraging the CDISC Standards to Facilitate the use of Electronic Source Data within Clinical Trials (Online reference: )

-----------------------

Meetings

Protocol

Test if system and its functionalities is Installed, Operates and Performs as required

3 IQ

Document functionalities and program scripts

4 OQ

2 FS

1 URS

5 PQ

Bind all Validation documents and describe all deviations which were unsolved during the Validation Process

6 VR

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download