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(
Cerebellis | Digitalis |
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 |
Version | Date | Description |
1 | 2019-08-30 09:46:38 | first release |
Redactor | Relector | Relector | Approvor | |
Name | Euzen Marie | Pucheu Marion | Noyon Laurent | Perraudin Thomas |
Role | Computer System Validation Specialist | Process Owner | Technical Unit | Business Responsible |
Date | ||||
Signature | ||||
Meaning of Signature | I 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. |
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:
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.
Regulation | Detailed Description |
CE Regulation and European directive | EudraLex Volume 4 – Annex 11 « Computerised Systems » and Annex 15 « Qualification and Validation » |
ICH Topic E6 | International Conference on Harmonization - Guideline for Good Clinical Practices |
FDA 21 CFR (Code of Federal Regulations) Part 11 | Electronic Records, Electronic Signatures – Final Rule |
GAMP5 | A Risk-based Approach to Compliant GxP Computerised Systems |
PIC/S Guidance (PI011) | Good Practices for Computerised Systems in Regulated « GXP » Environments |
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).
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 …)
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.
Abbreviation | Description |
CAPA | Corrective Action and Preventive Action |
CFR | Code of Federal Regulation |
CSV | Computer System Validation |
ECRF | electronic Case Report Form |
EDC | Electronic Data Capture |
ICH | International Conference on Harmonisation |
FDA | Food and Drugs Administration |
FS | Functional Specifications |
GAMP | Good Automated Manufacturing Practices |
IQ | Installation Qualification |
IT | Information Technology |
ODM | Operational Data Model |
OQ | Operational Qualification |
PQ | Performance Qualification |
QA | Quality Assurance |
SOP | Standard Operating Procedure |
URS | User Requirements Specifications |
VP | Validation Plan |
Term | Definition |
CAPA | Set of actions to take in documentation, procedures, or systems to rectify and eliminate non-conformities. |
ECRF | Electronic forms dedicated to clinical data collection. |
EDC | Computerized system designed for the collection of clinical data in electronic format. |
ODM | The 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. |
SOP | Set 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. |
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:
o
Accounts
o
Administration
o
Clinical
data
o
Databases
o
Study
design
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.
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.
Role | Identified Unit (Department/Area) |
Business Owner | Cerebellis General Department |
Technical Unit | Cerebellis IT Department |
Quality Unit | Cerebellis Quality Department |
Three
separate environments (hardware and software components) are available:
Following
tools are used:
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.
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.
Based on
GAMP5 classification DIGITALIS is a Category 4 system.
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
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Acceptance Criteria ID | Acceptance Criteria Description |
AC-1 | The system functionalities comply with user requirements and the regulations (approved documentation and qualifications performed). |
AC-2 | There are no malfunctions with the system functionalities (no open non-conformity) |
AC-3 | The system is available and operates adequately in use (successful PQ). |
AC-4 | The validation steps and deliverables comply with the Validation Plan (with deviations from VP well justified if any). |
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.
Role | Responsibilities | Name, function / company | Project | Operation |
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 Training | Cerebellis, Thomas Perraudin | x | x |
Business Responsible | • Carries out project management • Perform CSV documentation maintenance or allocates resources to do so • User Training | Cerebellis, Thomas Perraudin | x | |
Key User | • Trained to use the system • Execute qualification tests protocols | x | ||
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 phase | Cerebellis, Laurent Noyon | x | x |
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 Euzen | x | |
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 validation | Writee, Marie Euzen | x | |
QA | • Responsible for Quality Assurance and regulatory support during the operational phase • Review and approval of Procedure if any • Validation anomalies review if needed | Cerebellis, Thomas Perraudin | x |
The list of
deliverables for the validation of Digitalis is summarized in the matrix below,
with the following roles and responsibilities:
Delivrable | Process Owner | Business Responsible | Key User | Technical Unit | CSV | QA |
Analysis /Design Phase | Analysis /Design Phase | Analysis /Design Phase | Analysis /Design Phase | Analysis /Design Phase | Analysis /Design Phase | Analysis /Design Phase |
User Requirement Specification (URS) | A | C | - | R | R | R |
Validation Plan (VP) | R | C | - | R | R | A |
Functional Specification (FS) | A | C | - | R | R | R |
Testing | Testing | Testing | Testing | Testing | Testing | Testing |
IQ Protocol & Report | R | I | I | A | R | R |
IQ Execution | I | I | A | R | R | R |
OQ Protocol & Report | A | I | I | R | R | R |
OQ Execution | I | I | A | R | R | R |
Implementation | Implementation | Implementation | Implementation | Implementation | Implementation | Implementation |
PQ Protocol & Report | A | I | I | R | R | R |
PQ Execution | R | C | A | I | R | R |
Validation Report | R | C | - | R | R | A |
Digitalis-User
Requirements Specification-version
1.0