2019-09-26 00:41:58 116 > = MASTER REQUEST (REGULAR) =================================================================== 2019-09-26 00:41:58 133 > Unauthorized access from 31.35.149.224 2019-09-26 00:41:58 134 > - Page generation for '404' 2019-09-26 00:41:59 393 > = MASTER REQUEST (REGULAR) =================================================================== 2019-09-26 00:41:59 393 > Unauthorized access from 31.35.149.224 2019-09-26 00:41:59 394 > - Page generation for '404' 2019-09-26 00:41:59 669 > = MASTER REQUEST (REGULAR) =================================================================== 2019-09-26 00:41:59 669 > Unauthorized access from 31.35.149.224 2019-09-26 00:41:59 670 > - Page generation for '404' 2019-09-26 00:41:59 817 > = MASTER REQUEST (REGULAR) =================================================================== 2019-09-26 00:41:59 817 > Unauthorized access from 31.35.149.224 2019-09-26 00:41:59 817 > - Page generation for '404' 2019-09-26 00:42:00 201 > = MASTER REQUEST (REGULAR) =================================================================== 2019-09-26 00:42:00 202 > Unauthorized access from 31.35.149.224 2019-09-26 00:42:00 202 > - Page generation for '404' 2019-09-26 00:42:08 862 > = MASTER REQUEST (REGULAR) =================================================================== 2019-09-26 00:42:08 863 > - Page generation for 'dashboard' 2019-09-26 00:42:09 574 > = MASTER REQUEST (REGULAR) =================================================================== 2019-09-26 00:42:09 575 > Unauthorized access from 31.35.149.224 2019-09-26 00:42:09 575 > - Page generation for '404' 2019-09-26 00:42:11 431 > = AJAX ACTION REQUEST ============================================================================ 2019-09-26 00:42:11 432 > back\coreaxcontroller::getAction(project.setProject) 2019-09-26 00:42:11 467 > = AJAX ACTION REQUEST ============================================================================ 2019-09-26 00:42:11 467 > back\coreaxcontroller::getAction(project.getDataListDB) 2019-09-26 00:42:11 479 > back\boresource::getDataList(project as project INNER JOIN __acl as acl ON project.id = acl.id_project, WHERE (acl.id_user = 5)) 2019-09-26 00:42:11 741 > = MASTER REQUEST (AJAX) =================================================================== 2019-09-26 00:42:11 742 > - Page generation for 'dashboard' 2019-09-26 00:42:11 884 > = AJAX ACTION REQUEST ============================================================================ 2019-09-26 00:42:11 884 > back\coreaxcontroller::getAction(project.getDataListDB) 2019-09-26 00:42:11 886 > back\boresource::getDataList(project as project INNER JOIN __acl as acl ON project.id = acl.id_project, WHERE (acl.id_user = 5)) 2019-09-26 00:42:20 923 > = AJAX ACTION REQUEST ============================================================================ 2019-09-26 00:42:20 942 > back\coreaxcontroller::getAction(project.setProject) 2019-09-26 00:42:20 943 > back\boresource::get(project, 40) 2019-09-26 00:42:20 988 > = AJAX ACTION REQUEST ============================================================================ 2019-09-26 00:42:20 988 > back\coreaxcontroller::getAction(document.getDocuments) 2019-09-26 00:42:21 981 > = MASTER REQUEST (AJAX) =================================================================== 2019-09-26 00:42:21 982 > - Page generation for 'document/documents' 2019-09-26 00:42:22 032 > back\boresource::save(document) 2019-09-26 00:42:22 041 > back\boresource::get(document, 444) 2019-09-26 00:42:22 050 > back\boresource::get(project, 40) 2019-09-26 00:42:22 051 > back\boresource::get(project, 40) 2019-09-26 00:42:22 052 > back\boresource::getList(acl, Array ( [id_project] => 40 [id_user] => 5 ) ) 2019-09-26 00:42:22 071 > back\boresource::get(project, 40) 2019-09-26 00:42:22 162 > back\boresource::get(project, 40) 2019-09-26 00:42:22 163 > back\boresource::getList(acl, Array ( [id_project] => 40 [id_user] => 5 ) ) 2019-09-26 00:42:22 171 > back\boresource::get(project, 40) 2019-09-26 00:42:22 172 > back\boresource::getList(acl, Array ( [id_project] => 40 [id_user] => 5 ) ) 2019-09-26 00:42:22 195 > back\boresource::get(project, 40) 2019-09-26 00:42:22 196 > back\boresource::getList(acl, Array ( [id_project] => 40 [id_user] => 5 ) ) 2019-09-26 00:42:22 362 > = AJAX ACTION REQUEST ============================================================================ 2019-09-26 00:42:22 362 > back\coreaxcontroller::getAction(document.getDataList) 2019-09-26 00:42:22 365 > back\boresource::getDataList(project AS project INNER JOIN __document AS document ON (document.id_project = project.id), WHERE (project.id = 40 AND (document.validated = 0 OR (document.version = (select max(version) from __document where __document.key_doc = document.key_doc) and validated = 1)))) 2019-09-26 00:42:22 368 > = AJAX ACTION REQUEST ============================================================================ 2019-09-26 00:42:22 368 > back\coreaxcontroller::getAction(document.setButtons) 2019-09-26 00:42:22 373 > back\boresource::get(project, 40) 2019-09-26 00:42:22 374 > back\boresource::getList(acl, Array ( [id_project] => 40 [id_user] => 5 ) ) 2019-09-26 00:43:15 124 > = ACTION REQUEST ============================================================================ 2019-09-26 00:43:15 131 > back\coreaxcontroller::getAction(document.getDocumentPDF) 2019-09-26 00:43:15 133 > back\boresource::get(project, 40) 2019-09-26 00:43:15 136 > back\boresource::get(document, 444) 2019-09-26 00:43:15 147 > back\bodocument::getPDF(444) 2019-09-26 00:43:15 147 > back\boresource::get(document, 444) 2019-09-26 00:43:15 148 > back\boresource::get(document, 444) 2019-09-26 00:43:15 149 > back\boresource::get(chapter, 3239) 2019-09-26 00:43:15 150 > back\boresource::get(chapter, 3240) 2019-09-26 00:43:15 152 > back\boresource::get(chapter, 3241) 2019-09-26 00:43:15 153 > back\boresource::get(chapter, 3242) 2019-09-26 00:43:15 155 > back\boresource::get(chapter, 3243) 2019-09-26 00:43:15 156 > back\boresource::get(chapter, 3244) 2019-09-26 00:43:15 158 > back\boresource::get(chapter, 3245) 2019-09-26 00:43:15 159 > back\boresource::get(chapter, 3246) 2019-09-26 00:43:15 160 > back\boresource::get(chapter, 3247) 2019-09-26 00:43:15 162 > back\boresource::get(chapter, 3248) 2019-09-26 00:43:15 163 > back\boresource::get(chapter, 3249) 2019-09-26 00:43:15 164 > back\boresource::get(chapter, 3250) 2019-09-26 00:43:15 165 > back\boresource::get(chapter, 3251) 2019-09-26 00:43:15 167 > back\boresource::get(chapter, 3252) 2019-09-26 00:43:15 168 > back\boresource::get(chapter, 3253) 2019-09-26 00:43:15 169 > back\boresource::get(chapter, 3254) 2019-09-26 00:43:15 170 > back\boresource::get(chapter, 3255) 2019-09-26 00:43:15 171 > back\boresource::get(chapter, 3256) 2019-09-26 00:43:15 172 > back\boresource::get(chapter, 3257) 2019-09-26 00:43:15 174 > back\boresource::get(chapter, 3258) 2019-09-26 00:43:15 175 > back\boresource::get(chapter, 3259) 2019-09-26 00:43:15 176 > back\boresource::get(chapter, 3260) 2019-09-26 00:43:15 177 > back\boresource::get(chapter, 3261) 2019-09-26 00:43:15 179 > back\boresource::get(chapter, 3262) 2019-09-26 00:43:15 180 > back\boresource::get(chapter, 3263) 2019-09-26 00:43:15 181 > back\boresource::get(chapter, 3264) 2019-09-26 00:43:15 183 > back\boresource::get(chapter, 3265) 2019-09-26 00:43:15 184 > back\boresource::get(chapter, 3266) 2019-09-26 00:43:15 186 > back\boresource::get(chapter, 3267) 2019-09-26 00:43:15 187 > back\boresource::get(chapter, 3268) 2019-09-26 00:43:15 188 > back\boresource::get(chapter, 3269) 2019-09-26 00:43:15 189 > back\boresource::get(chapter, 3270) 2019-09-26 00:43:15 191 > back\boresource::get(chapter, 3271) 2019-09-26 00:43:15 192 > back\boresource::get(chapter, 3272) 2019-09-26 00:43:15 193 > back\boresource::get(chapter, 3273) 2019-09-26 00:43:15 194 > back\boresource::get(chapter, 3274) 2019-09-26 00:43:15 196 > back\boresource::get(chapter, 3275) 2019-09-26 00:43:15 197 > back\boresource::get(chapter, 3276) 2019-09-26 00:43:15 198 > back\boresource::get(chapter, 3277) 2019-09-26 00:43:15 199 > back\boresource::get(chapter, 3278) 2019-09-26 00:43:15 201 > back\boresource::get(chapter, 3279) 2019-09-26 00:43:15 202 > back\boresource::get(chapter, 3280) 2019-09-26 00:43:15 203 > back\boresource::get(chapter, 3281) 2019-09-26 00:43:15 204 > back\boresource::get(chapter, 3282) 2019-09-26 00:43:15 206 > back\boresource::get(chapter, 3283) 2019-09-26 00:43:15 207 > back\boresource::get(chapter, 3284) 2019-09-26 00:43:15 208 > back\boresource::get(chapter, 3285) 2019-09-26 00:43:15 209 > back\boresource::get(document, 444) 2019-09-26 00:43:15 210 > back\boresource::get(chapter, 3239) 2019-09-26 00:43:15 211 > back\boresource::get(chapter, 3240) 2019-09-26 00:43:15 212 > back\boresource::get(chapter, 3241) 2019-09-26 00:43:15 213 > back\boresource::get(chapter, 3242) 2019-09-26 00:43:15 214 > back\boresource::get(document, 444) 2019-09-26 00:43:15 214 > back\boresource::get(regulatory, 73) 2019-09-26 00:43:15 215 > back\boresource::get(regulatory, 74) 2019-09-26 00:43:15 216 > back\boresource::get(regulatory, 75) 2019-09-26 00:43:15 217 > back\boresource::get(regulatory, 76) 2019-09-26 00:43:15 218 > back\boresource::get(regulatory, 77) 2019-09-26 00:43:15 218 > back\boresource::get(chapter, 3243) 2019-09-26 00:43:15 219 > back\boresource::get(chapter, 3244) 2019-09-26 00:43:15 220 > back\boresource::get(chapter, 3245) 2019-09-26 00:43:15 221 > back\boresource::get(chapter, 3246) 2019-09-26 00:43:15 222 > back\boresource::get(document, 444) 2019-09-26 00:43:15 223 > back\boresource::get(glossary, 217) 2019-09-26 00:43:15 224 > back\boresource::get(glossary, 218) 2019-09-26 00:43:15 224 > back\boresource::get(glossary, 219) 2019-09-26 00:43:15 225 > back\boresource::get(glossary, 220) 2019-09-26 00:43:15 226 > back\boresource::get(glossary, 221) 2019-09-26 00:43:15 226 > back\boresource::get(glossary, 222) 2019-09-26 00:43:15 227 > back\boresource::get(glossary, 223) 2019-09-26 00:43:15 228 > back\boresource::get(glossary, 224) 2019-09-26 00:43:15 228 > back\boresource::get(glossary, 225) 2019-09-26 00:43:15 229 > back\boresource::get(glossary, 226) 2019-09-26 00:43:15 230 > back\boresource::get(glossary, 227) 2019-09-26 00:43:15 230 > back\boresource::get(glossary, 228) 2019-09-26 00:43:15 231 > back\boresource::get(glossary, 229) 2019-09-26 00:43:15 232 > back\boresource::get(glossary, 230) 2019-09-26 00:43:15 232 > back\boresource::get(glossary, 231) 2019-09-26 00:43:15 233 > back\boresource::get(glossary, 232) 2019-09-26 00:43:15 234 > back\boresource::get(glossary, 233) 2019-09-26 00:43:15 235 > back\boresource::get(glossary, 234) 2019-09-26 00:43:15 235 > back\boresource::get(chapter, 3247) 2019-09-26 00:43:15 236 > back\boresource::get(document, 444) 2019-09-26 00:43:15 237 > back\boresource::get(definition, 36) 2019-09-26 00:43:15 238 > back\boresource::get(definition, 37) 2019-09-26 00:43:15 239 > back\boresource::get(definition, 38) 2019-09-26 00:43:15 240 > back\boresource::get(definition, 39) 2019-09-26 00:43:15 240 > back\boresource::get(definition, 40) 2019-09-26 00:43:15 241 > back\boresource::get(chapter, 3248) 2019-09-26 00:43:15 242 > back\boresource::get(chapter, 3249) 2019-09-26 00:43:15 243 > back\boresource::get(chapter, 3250) 2019-09-26 00:43:15 244 > back\boresource::get(chapter, 3251) 2019-09-26 00:43:15 245 > back\boresource::get(chapter, 3252) 2019-09-26 00:43:15 246 > back\boresource::get(chapter, 3253) 2019-09-26 00:43:15 247 > back\boresource::get(chapter, 3254) 2019-09-26 00:43:15 248 > back\boresource::get(chapter, 3255) 2019-09-26 00:43:15 249 > back\boresource::get(chapter, 3256) 2019-09-26 00:43:15 250 > back\boresource::get(chapter, 3257) 2019-09-26 00:43:15 251 > back\boresource::get(chapter, 3258) 2019-09-26 00:43:15 252 > back\boresource::get(chapter, 3259) 2019-09-26 00:43:15 253 > back\boresource::get(chapter, 3260) 2019-09-26 00:43:15 254 > back\boresource::get(chapter, 3261) 2019-09-26 00:43:15 255 > back\boresource::get(chapter, 3262) 2019-09-26 00:43:15 256 > back\boresource::get(chapter, 3263) 2019-09-26 00:43:15 257 > back\boresource::get(chapter, 3264) 2019-09-26 00:43:15 258 > back\boresource::get(chapter, 3265) 2019-09-26 00:43:15 259 > back\boresource::get(chapter, 3266) 2019-09-26 00:43:15 260 > back\boresource::get(chapter, 3267) 2019-09-26 00:43:15 261 > back\boresource::get(chapter, 3268) 2019-09-26 00:43:15 262 > back\boresource::get(chapter, 3269) 2019-09-26 00:43:15 263 > back\boresource::get(chapter, 3270) 2019-09-26 00:43:15 264 > back\boresource::get(chapter, 3271) 2019-09-26 00:43:15 265 > back\boresource::get(chapter, 3272) 2019-09-26 00:43:15 266 > back\boresource::get(chapter, 3273) 2019-09-26 00:43:15 267 > back\boresource::get(chapter, 3274) 2019-09-26 00:43:15 268 > back\boresource::get(chapter, 3275) 2019-09-26 00:43:15 268 > back\boresource::get(chapter, 3276) 2019-09-26 00:43:15 269 > back\boresource::get(chapter, 3277) 2019-09-26 00:43:15 270 > back\boresource::get(chapter, 3278) 2019-09-26 00:43:15 271 > back\boresource::get(chapter, 3279) 2019-09-26 00:43:15 272 > back\boresource::get(chapter, 3280) 2019-09-26 00:43:15 273 > back\boresource::get(chapter, 3281) 2019-09-26 00:43:15 274 > back\boresource::get(chapter, 3282) 2019-09-26 00:43:15 275 > back\boresource::get(chapter, 3283) 2019-09-26 00:43:15 276 > back\boresource::get(chapter, 3284) 2019-09-26 00:43:15 277 > back\boresource::get(chapter, 3285) 2019-09-26 00:43:15 278 > back\boresource::get(document, 444) 2019-09-26 00:43:15 396 > back\bodocument::generatePDF(











Digitalis
Validation Plan
CerebellisDigitalis
Reference : Digitalis_VP
Date : 2019-09-26
Version : 1
Status : Signed
Author : Euzen Marie
This document is confidential and may not be released without the prior consent of Cerebellis
Versions

VersionDateDescription
12019-08-30 09:46:38first release


Signatures

RedactorRelectorRelectorApprovor
NameEuzen MariePucheu Marion Noyon LaurentPerraudin Thomas
RoleComputer System Validation SpecialistProcess OwnerTechnical UnitBusiness Responsible
Date
Signature
Meaning of SignatureI confirm that the execution of the plan will produce a system compliant with applicable procedures and regulations.I confirm that the validation plan includes all activities and deliverables suitable for managing quality on this project. I will execute this plan according to my responsibility, delivering a system fit for supporting business processes. I confirm that the validation plan includes all activities and deliverables suitable for managing quality on this project. I will execute this plan according to my responsibility, delivering a system fit for technical processes. I confirm that the validation plan includes all activities and deliverables suitable for managing quality on this project. I confirm that the execution of the plan will produce a system compliant with applicable procedures and regulations.
Table of contents



  • 1. Introduction
  • 1.1. Purpose
  • 1.2. Scope
  • 1.2.1. Regulatory Scope
  • 1.2.2. System scope & limitations

  • 1.3. System Overview

  • 2. Acronyms & Definitions
  • 2.1. Acronyms
  • 2.2. Definitions

  • 3. System Definition
  • 3.1. System Description
  • 3.2. Hardware architecture and location
  • 3.3. System responsibilities
  • 3.4. System Responsibilities table
  • 3.5. System environments
  • 3.6. Configuration Management
  • 3.6.1. Tools
  • 3.6.2. Version Numbering
  • 3.6.3. Process


  • 4. Risk Management Approach
  • 4.1. Risk Assessment
  • 4.2. Functional Risk Assessment

  • 5. Validation Strategy
  • 5.1. Traceability
  • 5.2. Analysis and Design
  • 5.3. Installation Qualification
  • 5.3.1. Steps
  • 5.3.2. Documentation and Records

  • 5.4. Operational Qualification
  • 5.4.1. Steps
  • 5.4.2. Documentation and Records

  • 5.5. Deviations Management
  • 5.5.1. Deviations from requirements and specifications (Incidents)
  • 5.5.2. Deviations from the validation plan


  • 6. Validation Reports
  • 6.1. Qualification reports
  • 6.2. Phases sequence
  • 6.3. Conditional Acceptance
  • 6.4. Final Acceptance
  • 6.5. Validation Report
  • 6.6. Validation Report Table
  • 6.7. Validation Report Follow

  • 7. Delivrable Matrix
  • 7.1. Roles and Responsibilities
  • 7.2. Delivrables
  • 7.3. Delivrables Table

  • 8. References
  • 1. Introduction

  • 1.1. Purpose
  • The purpose of this Validation Plan (VP) is to define the strategy, activities, deliverables and responsibilities to be performed for the validation of the DIGITALIS system.

    Its goal is to set the principles to:

    • Bring evidences that involved processes are compliant with quality and regulatory requirements,
    • Ensure the safety and integrity of critical data.

    The objective of validation is to demonstrate with a high level of confidence that the system DIGITALIS will operate correctly when used, in terms of the scope of use described in user requirements specifications and detailed functional specifications of the system.

    The results of the validation will be described in a Validation Report.



  • 1.2. Scope
  • 1.2.1. Regulatory Scope
  • RegulationDetailed Description
    CE Regulation and European directiveEudraLex Volume 4 – Annex 11 « Computerised Systems » and Annex 15 « Qualification and Validation »
    ICH Topic E6International Conference on Harmonization - Guideline for Good Clinical Practices
    FDA 21 CFR (Code of Federal Regulations) Part 11Electronic Records, Electronic Signatures – Final Rule
    GAMP5A Risk-based Approach to Compliant GxP Computerised Systems
    PIC/S Guidance (PI011)Good Practices for Computerised Systems in Regulated « GXP » Environments


  • 1.2.2. System scope & limitations
  • This validation procedure embraces all computerized and automatized systems used by process in the scope of Digitalis, including user interfaces and automated processes for data collection, data management, user accounts management and system administration.

    The Digitalis application of the system is composed of a core application, an intermediate programming layer for specific adaptations, and a configuration depending on the end user requirements. The intermediate programming layer and configuration are not included in the scope of validation.

    This is described in the user requirements specifications and in the detailed functional specifications documents.

    It doesn’t include:

    ·         Text or spreadsheet documents without macros,

    ·         Software used in processes outside scope: accounting, legal, interfaced software…

    ·         The IT infrastructure managed through the xxx procedure (your procedure).




  • 1.3. System Overview
  • The eCRF solution by Cerebellis is composed of Digitalis and ODM Designer:

    1.       Digitalis is the interface to manage the subjects and enter the data,

    2.       ODM Designer is like a back office where it is possible to design a study and its protocol (study events, forms, items …)




  • 2. Acronyms & Definitions

  • Digitalis is an EDC system, a computerized system designed for the collection of clinical data in electronic format

    This document describes the different validation steps related to Digitalis® as an EDC system that complies with 21 CFR 11, ICH GCP guidelines and is consistent with FDA guidance on electronic systems used in clinical trials and abide CDISC standards.


  • 2.1. Acronyms
  • AbbreviationDescription
    CAPACorrective Action and Preventive Action
    CFRCode of Federal Regulation
    CSVComputer System Validation
    ECRFelectronic Case Report Form
    EDCElectronic Data Capture
    ICHInternational Conference on Harmonisation
    FDAFood and Drugs Administration
    FSFunctional Specifications
    GAMPGood Automated Manufacturing Practices
    IQInstallation Qualification
    ITInformation Technology
    ODMOperational Data Model
    OQOperational Qualification
    PQPerformance Qualification
    QAQuality Assurance
    SOPStandard Operating Procedure
    URSUser Requirements Specifications
    VPValidation Plan


  • 2.2. Definitions
  • TermDefinition
    CAPASet of actions to take in documentation, procedures, or systems to rectify and eliminate non-conformities.
    ECRFElectronic forms dedicated to clinical data collection.
    EDCComputerized system designed for the collection of clinical data in electronic format.
    ODMThe CDISC Operational Data Model (ODM) is designed to facilitate the regulatory-compliant acquisition, archive and interchange of metadata and data for clinical research studies. ODM is a vendor-neutral, platform-independent format for interchange and archive of clinical study data.
    SOPSet of detailed, written instructions on how to perform a routine business activity with efficiency, quality output and uniformity of performance, explain the process being described, and help comply with industry regulations.



  • 3. System Definition

  • 3.1. System Description
  • The eCRF solution by Cerebellis is composed of Digitalis and ODM Designer:

    1.       Digitalis is the interface to manage the subjects and enter the data,

    2.       ODM Designer is like a back office where it is possible to design a study and its protocol (study events, forms, items …)

     

    The Digitalis system is composed of the following components and sub-components:

    •         Account validation
    •          Authentication
    •          Dashboard
    •          Documents
    •         Manage:

    o    Accounts

    o    Administration

    o    Clinical data

    o    Databases

    o    Study design

    •         Orders
    •          Subject forms (eCRF)
    •          Subjects list
    •          Queries
    •         User profile


  • 3.2. Hardware architecture and location
  • This project is based on a system installed on a web server. This web server is a dedicated virtual machine provided by a hosting company (OVH) and physically situated in Gravelines, France.



  • 3.3. System responsibilities
  • The installation and maintenance of the physical and system environment are under the responsibility of Cerebellis IT Department.

    The system ownership is under the responsibility of Cerebellis General Department.

    The system validation status is under the responsibility of the business owners.



  • 3.4. System Responsibilities table
  • RoleIdentified Unit (Department/Area)
    Business OwnerCerebellis General Department
    Technical UnitCerebellis IT Department
    Quality UnitCerebellis Quality Department


  • 3.5. System environments
  • Three separate environments (hardware and software components) are available:

    1. Development: This environment is dedicated to the technical staff for program development. It is hosted on developer’s local virtual machines.
    2. Test/Validation: This environment is dedicated to the technical staff for testing before implementation in production environment. This environment, where the validation testing is performed (IQ, OQ), is controlled: it is independent, equivalent or representative of the production environment. It also is the environment used for PQ test only once IQ and OQ phases have been closed. It is hosted on a dedicated virtual machine provided by OVH.
    3. Production: This environment is dedicated to the end users for their use. This environment is controlled: only authorized personnel are granted access to it. It is equivalent to the final Test/Validation and is only installed for clients’ use. It is installed following the same process than the qualified Test/Validation environment.


  • 3.6. Configuration Management
  • 3.6.1. Tools
  • Following tools are used:

    •          Mantis: issues (proposals for change: corrections, evolutions or adaptations) are tracked and managed with Mantis Bug Tracker, an open source and web-based issue tracking manager hosted by Cerebellis.
    •         Git: Digitalis source code is backup and stored in a code repository manage by Git, an open source version control system hosted by Cerebellis. The list of modifications to be released are also tracked with Git.


  • 3.6.2. Version Numbering
  • Version number is stored in the source code of Digitalis in the format YY.MM[.mm] where YY stands for the year, MM for the month, and mm is optional for modifications released during the month if any.



  • 3.6.3. Process
  • Mantis issues are selected upon development of a new version of Digitalis and correspond to change requests. Impact on processes and records, configuration items and documentation are assessed collectively by Business Owner, Technical Unit and Quality Unit before acceptation of issues for the new development. Assessment details are based on business, technical and quality considerations that are reported in Mantis for each assessed issue. Details may concern product management (i.e. marketing point of view), source code management (e.g. code reviews, refactoring, components integration, etc.), and quality management (e.g. conformity to existing or new regulations).

    Documentation, tests and eventual other impacted items (training, procedures, etc.) are updated in accordance with implemented issues.





  • 4. Risk Management Approach

  • 4.1. Risk Assessment
  • The risk will be assessed by determining an overall risk for each requirement and specification based on a combination of risk Severity and risk Probability and risk Detectability as follows:

    Severity: Impact on Patient Safety, Product Quality, and Data Integrity (or other harm)

    Probability: Likelihood of the fault occurring

    Risk Class = Severity x Probability

    Detectability: Likelihood that the fault will be noted before harm occurs

    Risk = Risk Class x Detectability



  • 4.2. Functional Risk Assessment
  • The risk of requirements and functional specifications will be performed in the corresponding deliverables (URS and FS). Each requirement and functional specification will be assessed as described in the previous section.

    During the Qualification phases tests will be designed based on the Risk assessed to show all functionalities work as designed or that an efficient functional or technical measure is in place to mitigate any risk of failure:

    •           High risk (scores 1 and 2) URS and FS will be tested directly with positive and negative test cases with evidences.
    •           Medium risk (scores 3 and 4) URS and FS will be tested directly at least with positive test cases with evidences if they provide additional value to the test (context, cover multiple steps / tests, etc.).
    •           Low Risk (scores 6 and 9) URS and FS may be tested indirectly via testing of other functionalities or during PQ.





  • 5. Validation Strategy

  • The validation strategy consists in the validation phases:

    ·         Analysis and Design:

    o    User Requirements Specifications (URS): it describes the business needs for what users require from the system.

    o    Functional Specification (FS): it specifies the functions that a system or component must perform and that answers needs from the URS.

    o    Validation Plan (VP): it defines the scope and goals of a validation project.

    ·         Installation Qualification (IQ): it describes the process that is to be followed when installing the system in an environment. This environment may be a testing, validation, or production environment. IQ represents the controls, instructions and verification steps of the successful installation into the new environment.

    ·         Operational Qualification (OQ): it includes functionality test steps, test results, test reports and any testing problem reports.

    ·         Performance Qualification (PQ): It is a high-level testing based on a routine use workflow. It allows to verify that the procedures and computerized system work together and that routine users (with routine access levels) can actually operate the system in a compliant manner.

    Qualification is a systematic way of defining and verifying that the system is developed and installed in accordance with its specifications and is fit for purpose.


  • 5.1. Traceability
    •          User requirements and specifications are uniquely identified for traceability.
    •          The link between the requirements and the specifications developed to meet them is included in the design and qualification documentation.
    •          Each test performed will be linked to the system specifications(s) by indicating the specification(s) references(s) in regard of the test description or alternatively the test(s) reference(s) in regard of the system specification(s).


  • 5.2. Analysis and Design
  • Since the system has already been designed, the Analysis and Design Phase will only include the corresponding documentation with this VP, as well as URS and FS.



  • 5.3. Installation Qualification
  • 5.3.1. Steps
  • Installation qualification aims to ensure that computerized system is properly installed in the right environment.

    The scope of this IQ includes:

    ·         As the system is on the cloud, verifying:

    o    Cloud servers settings and characteristics,

    o    Contract with the cloud service provider,

    ·         Verifying that software environment settings and characteristics match environment requirements:

    o    Operating system version,

    o    Server web stack versions (web server and databases),

    ·         Verifying that software documentation is available and in the right version:

    o    Installation, administration and user manual,

    ·         Installing software, if applicable,

    ·         Verifying that software is properly installed:

    o    Software version,

    o    Installation results records (log files, screen shots…),

    ·         Configuring software,

    ·         Verifying that software is properly configured:

    o    Configuration settings,

    o    Configuration steps logs.



  • 5.3.2. Documentation and Records
  • The installation qualification documentation contains:

    ·         An installation qualification protocol containing all the verification/inspections required,

    ·         One or more installation qualification reports containing results of installation qualification,

    ·         Any additional record serving as evidence of installation qualification,

    ·         Bug reports found during installation qualification.




  • 5.4. Operational Qualification
  • 5.4.1. Steps
  • Operational qualification aims to ensure that every function of the computerized system is working as expected.

    The scope of OQ testing includes, as applicable:

    ·         Functional and performance requirements,

    o    Verifying software functions,

    o    Security, safety and privacy,

    ·         Non-functional requirements, like

    o    Administration functions,

    o    Maintenance functions,

    o    21 Part 11 compliance.



  • 5.4.2. Documentation and Records
  • The performance qualification documentation contains:

    ·         Optionally, a performance qualification protocol containing verifications of user requirements,

    ·         One or more performance qualification reports containing feedback of users, discovered bugs, …

    ·         Optionally, any record serving as evidence of performance qualification,

    ·         Bug reports found during performance qualification.




  • 5.5. Deviations Management
  • 5.5.1. Deviations from requirements and specifications (Incidents)
  • Deviations and software bugs are recorded in Mantis Bug Tracker.

    The severity of deviations is assessed with the following criteria:

    ·         Major: major non-compliance or functionality not working without a workaround,

    ·         Medium: non-compliance or functionality not working but with a workaround,

    ·         Minor: No non-compliance but software behavior is outside of specifications.

     

    The priority of deviations is assessed with the following criteria:

    ·         High: resolution cannot be postponed to a new version or is critical for compliance

    ·         Normal: resolution should be done without prior consideration

    ·         Low: resolution is neither considered as mandatory or urgent

     

    The responsibilities related to deviations management are:

    ·         Technical Unit, Business Owner and Quality can report deviations (whoever found it).

    ·         Technical Unit describes the technical analyses of the root cause of the deviation, proposes a corrective action and assesses technical impact for resolution.

    ·         Business Owner defines the severity and Quality defines the priority.

     

    Corrective action should include, where applicable, revision of requirements and specifications, version changes to software, and re-testing.

    All incidents must be analyzed and reviewed by QA.



  • 5.5.2. Deviations from the validation plan
  • Deviations during qualification testing like anomalies, incident and non-conformity reports or log, must be reviewed by the Business Responsible who will decide what should be done (amendment to this plan, further steps, amendments to protocols, etc.).

    Deviations from validation plan will be listed, and justified/explained in the validation report.





  • 6. Validation Reports

  • 6.1. Qualification reports
  • Reports are required to summarize each of the qualification phases of the validation project. 

    All qualification reports must address the following:

    ·         An overall summary of the results,

    ·         Inclusion or reference of the location of the qualification documentation (approved and executed tests protocols),

    ·         Discussion of all deviations, corrective actions, and resulting changes (especially bug fixes between IQ and OQ or OQ and PQ)

    ·         A conclusion that includes conditions for use of the system.



  • 6.2. Phases sequence
  • Successful completion of IQ as shown in the IQ report (with conditions if any) will allow to perform OQ.

    OQ completion will be summarized in the OQ report which will allow to move on to PQ (with conditions if any).

    IQ, OQ and PQ phases can be summarized in an intermediary Validation Report to allow release of the system with open non-blocking anomalies if any.

    Then the PQ phase will be carried out before the final Validation Report can be issued (again if an intermediary Validation Report was issued).

    A list of all anomalies which were detected during each qualification phase will be included in each qualification and validation report. Corrective measures and closure of all anomalies is required before issuing the Final Validation Report.



  • 6.3. Conditional Acceptance
  • If any anomaly remains open the system may be approved for use under certain conditions. These anomalies and acceptance conditions must be explained in the Validation Report that will remain as an Intermediary Validation Report until they are all cleared.



  • 6.4. Final Acceptance
  • Once all anomalies have been closed or after a significant period of operational use, the validation status of the system is re-evaluated in terms of the acceptance criteria to provide the Validated status to the system. This is summarized in the Final Validation Report.



  • 6.5. Validation Report
  • A Validation Report is required to verify the completion of all activities required by the validation protocol.

    The validation report must address the following:

    ·             An overall summary of the validation project,

    ·             A list of all deliverables generated as per the Validation Plan and their location,

    ·             Any deviation from the Validation Plan with justification,

    ·             A clear conclusion based on the acceptance criteria here below indicating whether or not the system is suitable for use in routine operations.



  • 6.6. Validation Report Table
  • Acceptance Criteria IDAcceptance Criteria Description
    AC-1The system functionalities comply with user requirements and the regulations (approved documentation and qualifications performed).
    AC-2There are no malfunctions with the system functionalities (no open non-conformity)
    AC-3The system is available and operates adequately in use (successful PQ).
    AC-4The validation steps and deliverables comply with the Validation Plan (with deviations from VP well justified if any).

    Acceptance criteria table

  • 6.7. Validation Report Follow
  • Each criterion is checked according to the following scale:

    ·         Compliant (C): no anomalies found.

    ·         Non-Compliant (NC): anomalies have been reported and the process of system implementation must then be deferred until they have been cleared up.

    ·         Non-Compliant but Accepted with conditions (CAC): anomalies have been reported but are not blocking, corrective measures and/or work-arounds have been defined (see section 6.4 Conditional Acceptance).

    The validation status of the system corresponds to the lowest level of compliance of the 4 criteria listed above.

    This evaluation, as well as the list of anomalies detected at the time of qualification or in production, and not cleared up after validation, is presented in the Validation Report.

    On the basis of these results, the Business owner/ Process Owner and the System Owner finally gives permission for the system to be used and record their decision by approving the Validation Report.




  • 7. Delivrable Matrix

  • 7.1. Roles and Responsibilities
  • RoleResponsibilitiesName, function / companyProjectOperation
    Process Owner• Writes and/or reviews URS • Writes and/or reviews FS in relation to the URS • Writes and/or supports writing of qualifications protocols • Supports qualification tests execution • Running tests for system changes • Key User TrainingCerebellis, Thomas Perraudinxx
    Business Responsible• Carries out project management • Perform CSV documentation maintenance or allocates resources to do so • User TrainingCerebellis, Thomas Perraudinx
    Key User• Trained to use the system • Execute qualification tests protocolsx
    Technical Unit• Technical support (installation and functionalities) if necessary • Writes or supports writing of FS • Writes and/or reviews qualification protocols • Support during qualifications / reviews anomalies • Establishment of infrastructure during the project and operational phases • Assistance with setting up the system during the project • Realization of system changes in accordance with the Functional Specifications • User Training • User support during the production phaseCerebellis, Laurent Noyonxx
    CSV• Writing Validation Plan and Report • Support and review for most qualification documents including o URS and FS (regarding risk analysis and regulatory compliance) o IQ, OQ, PQ protocols (preparation and execution review)Writee, Marie Euzenx
    QA• Responsible for Quality Assurance and regulatory support during the project phase • Review and approval of Procedure if any • Review and Approval of Validation Documents • Review validation anomalies if needed • Review and approval of changes during initial validationWritee, Marie Euzenx
    QA• Responsible for Quality Assurance and regulatory support during the operational phase • Review and approval of Procedure if any • Validation anomalies review if neededCerebellis, Thomas Perraudinx


  • 7.2. Delivrables
  • The list of deliverables for the validation of Digitalis is summarized in the matrix below, with the following roles and responsibilities:

    •          Responsible (R): Individual who contributes to the task completion within his area of expertise. There may be multiple Responsible for each task. The responsible is a mandatory approver of the deliverable.
    •         Accountable (A): Individual who is accountable of task completion. He may be responsible in his area of expertise. There is one and only one Accountable for each task. The accountable is a mandatory approver of the deliverable.
    •          Informed (I): Individual who is recommended to be consulted by the Accountable or any Responsible prior to the task completion and/or informed by the Accountable once the task has been completed.
    •          Consulted (C): Individual who is consulted for the task completion.


  • 7.3. Delivrables Table
  • DelivrableProcess OwnerBusiness ResponsibleKey UserTechnical UnitCSVQA
    Analysis /Design PhaseAnalysis /Design PhaseAnalysis /Design PhaseAnalysis /Design PhaseAnalysis /Design PhaseAnalysis /Design PhaseAnalysis /Design Phase
    User Requirement Specification (URS)AC-RRR
    Validation Plan (VP)RC-RRA
    Functional Specification (FS)AC-RRR
    TestingTestingTestingTestingTestingTestingTesting
    IQ Protocol & Report RIIARR
    IQ ExecutionIIARRR
    OQ Protocol & ReportAIIRRR
    OQ ExecutionIIARRR
    ImplementationImplementationImplementationImplementationImplementationImplementationImplementation
    PQ Protocol & ReportAIIRRR
    PQ ExecutionRCAIRR
    Validation ReportRC-RRA



  • 8. References

  • Digitalis-User Requirements Specification-version 1.0



    , 1, , Digitalis_VP- Version 1 - 2019-08-30 09:46:38- Signed -, Cerebellis - Digitalis, Validation Plan)