ALIX is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation. REGULATIONS COMPLIANCE ASSESSMENT BUSINESS & DECISION LIFE SCIENCES JANUARY 2012
TABLE OF CONTENT INTRODUCTION 1 REFERENCES 1 DISCLAIMER 1 TECHNICAL COMPLIANCE 2 HUMAN READABLE COPIES 2 AUDIT TRAIL 2 DATE/TIME STAMPS 3 INTERNAL SECURITY SAFEGUARDS 3 EXTERNAL SECURITY SAFEGUARDS 4 DIRECT ENTRY OF DATA 4 PROCEDURAL COMPLIANCE 5 STANDARD OPERATING PROCEDURES 5 RISK MANAGEMENT 5 VALIDATION 5 SYSTEM CONTROL 5 CHANGE CONTROLS AND ERROR REPORT SYSTEM 6 DATA STORAGE 6 SOFTWARE DEVELOPMENT 7 ENVIRONMENT 7 SUPPORT 7
INTRODUCTION References This document describes how regulations are implemented into the ALIX Software. References used in this document are the following: [21 CFR Part 11] The FDA 21 CFR Part 11, Electronic records; Electronic signatures [FDA Guidance] FDA, Guidance for Industry Computerized Systems Used in Clinical Investigations [EudraLex Annex 11] EudraLex, The Annex 11 : Computerized system of EudraLex The Rules Governing Medicinal Products in the European Union Volume 4 Good Manufactering Practice / Medicinal Products for Human and Veterinary Use [PIC/S] PIC/S Guidance, Good Practices For Computerised Systems In Regulated GxP Environments For each recommendation, text of the reference document is quoted and the ALIX corresponding implementation is described. Disclaimer The ALIX Software as used by Business & Decision Life Sciences is controlled by Business & Decision Life Sciences and is not subject to any third party modification under the GNU General Public License. Any third party users of the software are accountable for their own procedural use of the software. This document is owned by Business & Decision Life Sciences and could not be reproduced without an explicit authorization from Business & Decision Life Sciences. Copyright 2012 Business & Decision Life Sciences 1/7
TECHNICAL COMPLIANCE Human readable copies The ability to generate accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying by the agency. [21 CFR Part 11.10 (b)] It should be possible to obtain clear printed copies of electronically stored data. [EudraLex Annex 11 8.1] The ALIX Software natively stores data following the XML CDISC ODM 1.3 standard for both Clinical Data And MetaData. Printable copies of CRFs could be easily generated from these XML data, using the ALIX built-in PDF printout functionality. It also enables conversion to PDF, HTML or other human readable format with other software able to read CDISC ODM 1.3 XML Data. Audit Trail Audit trails or other security methods used to capture electronic record activities should describe when, by whom, and the reason changes were made to the electronic record. Original information should not be obscured though the use of audit trails or other security measures used to capture electronic record activities. [FDA Guidance : IV.D.2] Audit Trail is implemented at the core level of the ecrf. It is stored along with Clinical Data following the CDISC / ODM Standard. The ALIX Software records for each insertion/modification/deletion: User (login id) Timestamp (e.g. 2012-01-17T10:46:28+01:00) Reason for change (optional) Action at item level (Insert, Update or Remove) New value (previous value is still retained in the audit trail) Figure 1 - User view of Audit Trail on a field Copyright 2012 Business & Decision Life Sciences 2/7
Date/Time stamps We recommend that dates and times include the year, month, day, hour, and minute and encourage synchronization of systems to the date and time provided by international standard setting agencies (e.g., U.S. National Institute of Standards and Technology provides information about universal time, coordinated (UTC)). [FDA Guidance IV.D.3] System dates of computers from which the ALIX Software is accessed are never used. The system date used for audit trail and logging is the system date of the server running ALIX. This date is expressed with year, month, day, hour, minute, second with UTC offset information, e.g. 2012-01- 17T10:46:28+01:00. Internal Security Safeguards Access must be limited to authorized individuals (21 CFR 11.10(d)). This requirement can be accomplished by the following recommendations. We recommend that each user of the system have an individual account. The user should log into that account at the beginning of a data entry session, input information (including changes) on the electronic record, and log out at the completion of data entry session. The system should be designed to limit the number of log-in attempts and to record unauthorized access log-in attempts. [...] When someone leaves a workstation, the person should log off the system. Alternatively, an automatic log off may be appropriate for long idle periods. For short periods of inactivity, we recommend that a type of automatic protection be installed against unauthorized data entry (e.g., an automatic screen saver can prevent data entry until a password is entered). [FDA Guidance IV.D.1] Each user received a dedicated account with the following information: A login A password Maintaining the uniqueness of each combined identification code and password, such that no two individuals have the same combination of identification code and password. [21 CFR Part 11.300 (a)] Ensuring that identification code and password issuances are periodically checked, recalled, or revised (e.g., to cover such events as password aging). [21 CFR Part 11.300 (b)] Each user received a unique login. An expiration date could be set for each account. By default, the following configuration applied: After 3 unsuccessful attempts to login account is blocked After 3 unsuccessful attempts to login, IP is blocked Account or IP are blocked for 10 minutes When a blocking occurs, a notification is sent by email to the ecrf administrator Password should be changed every 90 days Copyright 2012 Business & Decision Life Sciences 3/7
Login attempts are logged into a table : Figure 2 - Login attempts log If there is no activity during a while (by default 15 minutes) the user session expires, and the user needs to log again into the system. External Security Safeguards You should maintain a cumulative record that indicates, for any point in time, the names of authorized personnel, their titles, and a description of their access privileges. That record should be kept in the study documentation, accessible for use by appropriate study personnel and for inspection by FDA investigators. [FDA Guidance IV.E] The ALIX Software maintains a list of current and past users who access the application. For past users, accounts are disabled so they cannot login into the application; In this way rights given to past users could be inspected at any time. To prevent a man in the middle attack which could compromise authenticity, integrity, and confidentiality of records, all connections are encrypted by a SSL Certificate provided by a Certificate Authority. Direct Entry of Data We recommend that you incorporate prompts, flags, or other help features into your computerized system to encourage consistent use of clinical terminology and to alert the user to data that are out of acceptable range. You should not use programming features that automatically enter data into a field when the field is bypassed (default entries). However, you can use programming features that permit repopulation of information specific to the subject. To avoid falsification of data, you should perform a careful analysis in deciding whether and when to use software programming instructions that permit data fields to be automatically populated. [FDA Guidance IV.F.1] The ALIX Software allows the ecrf Designer to add help features into the ecrf. Helps features could be inline messages, popup boxes, calculators (e.g. unit conversion). It also includes an advanced checking system to prevent entering of values outside acceptable range. Copyright 2012 Business & Decision Life Sciences 4/7
PROCEDURAL COMPLIANCE Standard Operating Procedures There should be specific procedures and controls in place when using computerized systems to create, modify, maintain, or transmit electronic records, including when collecting source data at clinical trial sites. [FDA Guidance IV.B] Business & Decision Life Sciences have specific procedures to handle ecrf processes: Setup of Study Development Environment Study Setup Custom Development Setup (SAE management, Randomization, Inclusion) Programming and Qualifying Edit Checks Sponsor Test Phase ecrf Study Go-Live Queries Management Database Lock / Unlock Data Export Risk management Risk management should be applied throughout the lifecycle of the computerised system taking into account patient safety, data integrity and product quality. As part of a risk management system, decisions on the extent of validation and data integrity controls should be based on a justified and documented risk assessment of the computerised system. [EudraLex Annex 11.1] Risk assessment is part of the Validation Plan Document established to conduct testing. For each version, the risk assessment section is updated to identify new risks and update existing risk levels. Validation Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. [21 CFR Part 11.10 (a)] A validation procedure ensures that each version and implementation of the ALIX Software is validated. This validation is based on a Validation Plan Document which includes a risk assessment to define the scope of the validation. An Automated Validation Software is used to run the validation plan, under the control of an observer. The use of an AVS allows running tests on all supported versions of browsers for each release. In case of bug discovered during testing, the operator fills a ticket in the issue tracker linked to version being tested into the Version Control System. System Control When electronic formats are the only ones used to create and preserve electronic records, sufficient backup and recovery procedures should be designed to protect against data loss. Records should Copyright 2012 Business & Decision Life Sciences 5/7
regularly be backed up in a procedure that would prevent a catastrophic loss and ensure the quality and integrity of the data. Records should be stored at a secure location specified in the SOP. Storage should typically be offsite or in a building separate from the original records. We recommend that you maintain backup and recovery logs to facilitate an assessment of the nature and scope of data loss resulting from a system failure. [ FDA Guidance IV.F.4] Backup procedure is described in a SOP, it consists of a daily backup to a offsite located at a long distance of the production site. A recovery disaster plan is also specified in a SOP. Change Controls and error report system The integrity of the data and the integrity of the protocols should be maintained when making changes to the computerized system, such as software upgrades, including security and performance patches, equipment, or component replacement, or new instrumentation. The effects of any changes to the system should be evaluated and some should be validated depending on risk. Changes that exceed previously established operational limits or design specifications should be validated. Finally, all changes to the system should be documented. [FDA Guidance IV.F.5] A Version Control System is used to track all software modifications. After each software update, an Automated Validation System is run on modified parts of the software to ensure the ALIX Software still works as expected. Along the Version Control System, an issue tracker traces bugs and new feature requests. New features must be declared into the issue tracker of the Version Control System with the corresponding new feature tag. Each new feature received a number, and is discussed by the developer team. Once approved, the new feature is linked to a planned release of ALIX. When implemented by the developer team, the feature number is indicated in the commit log, in this way the issue tracker entry for the new feature is updated to implemented. Same procedure applies for bug declaration and resolution. Before each release, new features added are reviewed and the Validation Plan Document is updated accordingly. Data Storage Regular back-ups of all relevant data should be done. Integrity and accuracy of backup data and the ability to restore the data should be checked during validation and monitored periodically. [EudraLex Annex 11 7.2] There should be written procedures for recovery of the system following a breakdown; these procedures should include documentation and record requirements to assure retrieval and maintenance of GxP information. [PIC/S 19.6] SOP ensures the backup of data to an offsite every day, with a retention period for each backup. SOP describes how to activate the Disaster Recovery Plan. Backups produce logs which are analyzed each day to ensure quality of the backups. On a regular basis, Disaster Recovery Plan is tested, and accordingly to the SOP, the simulation result is recorded into a log file. Copyright 2012 Business & Decision Life Sciences 6/7
SOFTWARE DEVELOPMENT Environment The ALIX Software code source is hosted in a Version Control System and following terms of GPL is freely available. Along the code source a Virtual Machine is provided, which contains all needed software to run ALIX out of the box. Support Business & Decision Life Sciences provides contracted support for his customers. Terms of support are customers specific and may cover hot fixes, software updates, hosting, recovery plan, validation documents, hotline and SOP. Any third party users of the ALIX software not covered by a Business & Decision Life Sciences support contract are accountable for their own procedural use of the software. Copyright 2012 Business & Decision Life Sciences 7/7