Standard Operating Procedures (SOPs) Research and Development Office Title of SOP: Computerised Systems for Clinical Trials SOP Number: 7 Version Number: 2.0 Supercedes: 1.0 Effective date: August 2013 Review date: August 2015 Author: Approved by: Alison Murphy, Research Manager Endorsed by Paul Carlin Dr David Hill Signed: Date: 01 August 2013 Document Number: SOP/RAD/SEHSCT/007 Page 1 of 17
Version History: Version No. Date Author Reason for Change 1.0 Oct 2007 Katrina Hughes N/A 2.0 Aug 2011 Alison Murphy Updated to new SOP format. Added guidance on validation, functional testing, management of data, security and the use of Microsoft Excel for recording trial data Document Number: SOP/RAD/SEHSCT/007 Page 2 of 17
Table of Contents 1. Introduction 2. Objective 3. Scope 4. Procedure 4.1 Evaluation and Purchasing 4.2 Validation and Functional Testing 4.3 Management of Electronic Data 4.4 Security 4.5 Use of Microsoft Excel for Clinical Trial Data 5. Regulations, Guidelines, References, SOP Links etc. 6. Appendices 6.1 Guidance for Validation and Functional Testing of Computerised Systems 6.2 Procedure for Data Management Using Microsoft EXCEL Document Number: SOP/RAD/SEHSCT/007 Page 3 of 17
1. INTRODUCTION ICH Guidelines for Good Clinical Practice (GCP) require that an electronic database should be fit for purpose; provide a clear audit trail; have security of access and be protected against deletions. The Data Protection Act 1998 requires data to be accurate and up to date, secure against loss, destruction, unlawful use or disclosure and to be processed fairly and lawfully. Research Data should be collected, recorded and managed in accordance with the principles of GCP, the Data Protection Act and the appropriate Trust procedures. All personal data and sensitive personal data must be managed in accordance with the principles of the Data Protection Act 1998. In particular, all personal data should be kept securely and not transmitted in a way that could cause loss of data or allow interception by unauthorised parties. All persons dealing with personal data are responsible for ensuring the security and safety of these data. Validation of computerised systems demonstrates that it is fit for purpose, performs consistently and the changes are effectively controlled. The validation will produce documentation that demonstrates that a system has indeed been validated and that the results of that validation were satisfactory. It is important that CIs make adequate provision for validating computerised systems and support of these systems after release in the funding arrangements for CTIMPs. It is the responsibility of the Chief Investigator (CI) in the clinical trial to ensure that any computerised system used during the study complies with the principles of ICH GCP, The Data Protection Act, Trust policies as well as EU and UK directives. 2. OBJECTIVE The objective of this Standard Operating Procedure (SOP) is to describe the procedure for validation and functional testing of computerised systems, and data collection, data management and security procedures for data held in trial databases in Clinical Trials of an Investigational Medicinal Product (CTIMPs). 3. SCOPE This Standard Operating Procedure (SOP) applies to all Clinical Trials of an Investigational Medicinal Product (CTIMPs) where the South Eastern Health and Social Care Trust (SEHSCT) is acting as the sponsor or co-sponsor, and are responsible for the computerised systems used to hold trial data. Document Number: SOP/RAD/SEHSCT/007 Page 4 of 17
4. PROCEDURE 4.1 Evaluation and Purchasing It is the CI s responsibility to ensure that any computerised systems that are used for clinical trial research are compliant with SEHSCT ICT evaluation and purchasing policies. 4.2 Validation and Functional Testing The CI must ensure when using electronic trial data and/or remote electronic trial systems that the system conforms to established requirements for completeness, accuracy, reliability and consistent intended performance. A description for the computerised system to be used in a CTIMP should be produced and retained in the Trial Master File (TMF), or other appropriate file. This document is the User Requirement Specification (URS). The validation and functional testing of the computerised system should be done against the documented description, User Requirement Specification for the computerised system. This document is the System Specification. The process of validation and functional testing should be recorded each time that it is carried out. Evidence of such testing should be retained in the TMF or other appropriate file. As modifications to the system are made, these should be functionally tested and validated. If necessary, updates to the User Requirement Specification and validation and functional testing regimes should be carried out. The validation status of a computerised system, both software and hardware, should be reviewed at least once every two years. Guidance on validation and functional testing of computerised systems can be found in appendix 1. 4.3 Management of Electronic Data The study protocol or other study document should clearly specify the data to be stored electronically and which data elements are to be retained upon archiving. Electronic data should be accurate and reliable. The computerised system should safeguard study blinding where this exists. Blinding should not be broken through day to day use of the computerised system. The system should provide protection against unintentional unblinding but support, where appropriate, any blinding procedures described in the protocol. Document Number: SOP/RAD/SEHSCT/007 Page 5 of 17
There will be an unambiguous and unique identifying ID for each participant. The code or file linking participant s names with their IDs should be kept secure and separate from the data used for trial analysis. Identifiable data should not be retained for longer than is necessary to meet the requirements described in the study protocol and to meet requirements set by grant awarding bodies, Research Ethics Committee and regulatory authorities, this is at least 5 years after the conclusion of the trial. Electronic data should be archived in a way that it is secure and which uses media with the appropriate longevity for the required storage time. If application software is required to read the archived data, this software should be archived together with the data. Deleting data may require the physical destruction of digital media. Following the archiving period permission should be sought from the sponsor before deleting or destroying any data. 4.4 Security Electronic data should only be stored on devices that are backed up in a secure and timely manner. Data should not be held on devices that do not participate in a backup regime. In practical terms this will generally mean: Liaising with Trust ICT Department to confirm that the server upon which the CTIMP database is stored is regularly (eg daily) backed-up onto remote and/or removable disk storage, the latter of which are then placed into a secure fire safe, and existence of disaster recovery procedures. The SEHSCT IT service has a data backup service that provides a reliable means of protecting data held on departmental file servers. ICT does not backup files on local desktop machines. Not using systems where the data are stored on the hard-disk of a PC or laptop unless secure backup arrangements are in place. Personal data must not be stored or transmitted on removable media or laptops without encryption. Any machines used to enter or access trial data should have up-to-date operating system patches installed together with appropriate security software (e.g. antivirus, antispyware, firewall) Data used for trial analysis should be anonymised. Date used for trial management should use the minimum number of personal identifiers necessary for study conduct and ensuring patient safety. Access to the data should be limited to authorised personnel and each user of the system should have an individual account. A record should be kept of authorised users and the access levels that apply to each user. The list of authorised users should be kept in the Trial Master File. Document Number: SOP/RAD/SEHSCT/007 Page 6 of 17
Accounts must never be shared, nor should there be guest accounts. Individual users should login with their own usernames and passwords. Individual users should not login so as to provide access to another user. Datasets should be encrypted prior to transmission or transfer. department can provide advice on encryption. The Trust ICT The study database should ideally have an audit trail for any changes made to electronic data after initial entry. For example, if a laboratory result is changed, the original value ought to remain in the database together with the date of the change, a brief explanation of why the change was made and who made the change. At the end of a trial, data should be locked to prevent further additions or changes to the data using the data management system s file-locking facility if such a facility exists, otherwise a snapshot of the data should be taken for analysis and access limited to authorised personnel. 4.5 Use of Microsoft Excel for Clinical Trial Data In a certain proportion of small-scale clinical trials, owing to their size and constraints on funding, there is little technical support for researchers in the design of databases in which to store clinical data. These trials will typically be trials where a small number of subjects are being recruited. In these trials commonly data are entered from Case Report Forms (CRF) into spreadsheets such as Microsoft Excel prior to transfer for statistical analysis. As EXCEL does not have an inbuilt audit trail of who has access to the data, or who can enter or amend the data specific procedures need to be followed to optimise compliance with the principles of The Medicines for Human Use (Clinical Trials) Regulations 2004 and GCP. The procedure to follow when using Microsoft Excel can be found in appendix 2. 5. REGULATIONS, GUIDELINES, REFERENCES, SOP LINKS etc. Statutory instrument 2004/1031: The Medicines for Human Use (Clinical Trials) regulations 2004. Statutory instrument 2006/1928: Amendment Regulations 2006. The Medicines for Human Use (Clinical Trials) ICH (1996). Guidelines for Good Clinical Practice ICH Harmonised Tripartite Agreement, Section 8. Gold A, Wells H, Tucker J et al. Computerised Systems Validation in Clinical Research. A Practical Guide. CR-CSV Working Party, Association for Clinical Data Management; 2004, 2 nd edition.) Data Protection Act 1998 Document Number: SOP/RAD/SEHSCT/007 Page 7 of 17
6. APPENDICES 6.1 Appendix 1 - Guidance for Validation and Functional Testing of Computerised Systems 6.2 Appendix 2 - Procedure for Data Management Using Microsoft EXCEL Document Number: SOP/RAD/SEHSCT/007 Page 8 of 17
6.1 Appendix 1 Guidance for Validation and Functional Testing of Computerised Systems Steps to consider 1. The Chief Investigator (CI) and other users of the computerised system should produce a User Requirements document, which describes the requirements of the system from their point of view. The user is free to include anything that is important and should not be constrained by considering how these needs will be met technically (see next point). 2. The User Requirements document should be version-controlled with a document history on the front page listing changes, who made them and when. 3. The User Requirements should be signed-off by the CI. 4. The System Specification takes the User Requirements and describes in detail the behaviours and properties of the system to be provided. These behaviours and properties should be testable, which should in turn enable the User Requirements to be achieved. 5. The System Specification document should be version-controlled with a document history on the front page listing changes, who made them and when. 6. The System Specification should be signed-off by the CI. 7. The User Requirements and System Specification documents should be kept in the Trial Master File (TMF), or other appropriate file. 8. A validation planning meeting should be held early in the planning of the CTIMP, which involves the IT team developing the system, the CI and other relevant staff. The key outcome of this meeting will be a validation plan listing the actions needed and documents required to demonstrate that the computerised system as specified in the System Specification meets the requirements listed in the User Requirements. A suggested validation plan is below. 9. To be validated, a system needs to demonstrate that it functions as expected. Functional testing of a computerised system should be done against a predefined test plan, both during and on completion of development. Test data should include (but need not be limited to): Representative data Extreme but realistic values Boundary values (ie. values just above or below a valid threshold for, say, a blood pressure measurement) Document Number: SOP/RAD/SEHSCT/007 Page 9 of 17
Missing values Incorrect values 10. At least two, suitably qualified people should manage, run and report the functional testing process (eg. the person who developed the system and a second person who tests it). 11. Test documentation should be signed-off by the person running the test. 12. The process of functional testing and validation should be recorded each time it is done. Documentary evidence of such testing should be retained in the TMF or other appropriate file. 13. The group involved in developing the validation plan should agree when the computerised system has been successfully validated. When validation is complete, the system should be signed-off by the CI and lead developer. 14. Computerised systems should not go live until validation is complete and the system has been signed-off 15. Changes to the computerised system and/or the User Specification may be required after release, either to correct an error, or to support an enhancement or modification in functionality, access, performance or regulatory requirement. In all cases the reason for any change should be identified and documented. When changes to the system are made, these should also be validated. 16. Version control should be used to track changes made to the system and its associated documentation. 17. The validation status of a computerised system, both software and hardware, should be reviewed at least once every two years. Document Number: SOP/RAD/SEHSCT/007 Page 10 of 17
Validation Plan Contents (This list is taken from Gold A, Wells H, Tucker J et al. Computerised Systems Validation in Clinical Research. A Practical Guide. CR-CSV Working Party, Association for Clinical Data Management; 2004, 2 nd edition.) The following summarises the broad areas that a validation plan should address: 1. Document Control A document control indicating the current version of the plan together with the revision history of the document 2. Approval of Plan A sheet indicating the signatories, with definition of scope of authorisation, for approval of the validation plan. 3. Introduction and Objective A brief statement as to what system is being developed, the business/regulatory case and the purpose of the document. 4. Description of System A brief description of the system, its use, and the hardware, operating system and network software on which it will run. 5. Risk Assessment A list of the risks to the validated state of the system and the extent to which they are addressed by the plan. 6. Scope of Validation A description of the extent of the validation exercise including: Constraints on the validation activities Assumptions made for the successful execution of the validation plan Boundaries to the validation activities, i.e a description of the points beyond which the validation testing will not run Exclusions of any specific areas within the scope with reasons why 7. Validation Process A detailed description of how the validation will be carried out (this may be in a separate document referenced from the Validation Plan) including: Validation approach/rationale, Validation SOPs to be followed, Operational use of system, e.g SOPs, for technical and end users, Document Number: SOP/RAD/SEHSCT/007 Page 11 of 17
Security and access, Training, Acceptance testing, Configuration management, Incident management, Change control, Support, 8. Tasks and Responsibilities A checklist of tasks and who is responsible for their execution, review and approval. 9. Documentation A list of the documentation that will be collated during the validation exercise including details of authors, reviewers and approvers of such documentation. The level of documentation required should be based on a risk assessment. 10. Quality Control Process A description of how the validation project will be managed, including key milestones and the review process. 11. Time-scales Relevant time-scales and dependencies 12. Validation Completion A definition of the requirements to be achieved for the system to go live. 13. Validation Maintenance A statement as to how the validated system will be maintained thereafter. This may refer to other procedures in place and should cover: Security and access, Training, Configuration Management, Incident Management, Support, Change control, Business continuity, Document Number: SOP/RAD/SEHSCT/007 Page 12 of 17
Periodic review, 14. Referenced Documents A list of documents, procedures and other supporting documentation referenced in the Validation Plan. Document Number: SOP/RAD/SEHSCT/007 Page 13 of 17
6.2 Appendix 2 Procedure for Data Management Using Microsoft EXCEL 1. Creation of data fields A Microsoft Excel file should be designed using Microsoft Excel to ensure that it captures all the information that is required according to the protocol. It should directly reflect the content of the Case Report Form (CRF) or other source data. 1.1 Worksheet identification Create sufficient worksheets within the Excel file to cover each visit. Enter the name of the visit on the worksheet tabs. Create additional worksheets to cover adverse event collection, concomitant medications etc. as applicable to the study. 1.2 Data field identification Within each visit worksheet, and through reference to the CRF, enter a heading for each variable as it appears on the CRF visit page. Each column should represent one variable. 1.3 Subject identification Each row should represent one subject. 1.4 Optional advanced settings To ensure that data added is accurate levels of validation can be added to the spreadsheet. Within certain fields, it is possible to restrict the type of data that can be added to a cell. Document Number: SOP/RAD/SEHSCT/007 Page 14 of 17
For example, if the column on the spreadsheet represents date of birth, selecting the date option form the validation criteria will only allow dates to be entered into that column. Furthermore, if the inclusion criteria of the study have a restriction on age range, a start and end date can be added. If the value is outside the settings, an error alert can be generated. To set validation criteria, select the cells to be affected; choose Data, Validation and set your criteria under Input, Settings and Error Alert. Example 2. Validation of Spreadsheet Once the spreadsheet design is considered to be complete, a validation process should be undertaken to ensure that it is fit for purpose, as below. 2.1 Create a sample CRF Enter data for a hypothetical participant, ensuring that all data boxes are complete. Include data entry on Adverse Events and Concomitant Medications pages. 2.2 Transfer data to database. Using the completed CRF, transfer all the data onto the Excel spreadsheet. Make a note of any difficulties involved in this process. Review each worksheet for errors or omissions. Document Number: SOP/RAD/SEHSCT/007 Page 15 of 17
2.3 Document validation Once the spreadsheet is considered to be fit for purpose the sample CRF and the printed spreadsheet should be filed as documentation of this process. 3. Creating and Using an Audit Trail 3.1 Preparing Read Only access. Once development of the spreadsheet is complete, create a folder to store the worksheets. Right click on the folder. Select Properties. Select General tab. Tick Read Only box and select OK. 3.2 Creating the trail Once data entry commences, the file will require saving as a new file on every occasion it is accessed. To save files chronologically and record the identity of the member of the team adding to data, save with the date reversed, the time, and initials. This method will automatically file the workbooks in chronological order. Example: 110324.1630.AM 110329.1115.AM 110329.1530.AM 3.3 Restricting Access Access should be restricted to the minimum number of personnel. A folder should be established within which all the trial spreadsheet files should be stored. The ICT department can advise you how to restrict access as this depends on what type of access you require for which staff members. 4. Quality Checks Unless you wish to undertake double data entry, it is important that periodic quality checks are conducted. You should form a plan for these prior to the study start and document this. It is good practice to check at least 10% of Case Report Forms against entries on the database. This involves a simple comparison of the data for accuracy of transcription. Ideally, someone other than the person entering the data should undertake this. These quality checks should be documented and filed within the study file. Queries are to be recorded by the Insert Comment facility available on EXCEL which also includes the name of the person raising the query. All queries must be clarified with the CI/PI and any actions recorded. Any changes to the paper CRF must be made by a single line drawn through, initialled and dated. The original data must be clearly visible. Data checking should continue until all missing data and/or inconsistent values have been corrected or clarified. Document Number: SOP/RAD/SEHSCT/007 Page 16 of 17
5. Confidentiality The participants will be identified in the database only by initials and a participant ID number. The study will comply with the Data Protection Act which requires data to be anonymised as soon as it is practical to do so. Names and any other identifying detail will NOT be included in any study data electronic file. Document Number: SOP/RAD/SEHSCT/007 Page 17 of 17