Validation des Systèmes d’Information ADAM Valérie Dates ...

Validation Systèmes d’Information – VSI (VQ050)VALIDATION DES SYSTÈMES INFORMATISÉSVQ051

© CVO-EUROPE – Tous droits réservés –

Validation des Systèmes d’Information

FORMATION INTERFORMATION INTER

ADAM ValérieDates : 25 Mai 2021Clase Virtuelle

VALIDATION DES SYSTÈMES INFORMATISÉS (DM/BPF)URGO MEDICAL AND HEALTHCARE

Référence VQ050

Présentation de marque

EFOR-CVO

Tou

s d

roit

s ré

serv

és -

20

21

EFOR-CVO la marque Life sciences du Groupe EFOR

3 PRÉSENTATION EFOR-CVO – 2021 – TOUS DROITS RÉSERVÉS

• sommaire NOTRE HISTOIRE

NOTRE PRÉSENCE

NOTRE AMBITION

NOTRE OFFRE

NOTRE VALEUR AJOUTÉE



LES DEUX GROUPES UNISSENT LEURS FORCES POUR DEVENIR LA RÉFÉRENCE EUROPÉENNE DU CONSEIL DES SCIENCES DE LA VIE

NOTRE HISTOIRE

CVO-EUROPE société de conseil reconnue depuis 1995 notamment dans l'industrie pharmaceutique avec une très forte présence dans tous les grands

comptes pharma en France et en Europe

1300 100M€ 16 AGENCESCollaborateurs de CA France, Belgique et Suisse

EFOR est un acteur majeur du conseil spécialisé et leader dans le monde des Life sciences

notamment pour les industriels des Dispositifs Médicaux depuis 2013

FIN 2020, CVO-EUROPE A INTÉGRÉ LE GROUPE EFOR


NOTRE AMBITION

Notre ambition est de consolider notre position deleader européen du conseil spécialisé en Life sciences.

Nous renforçons notre organisation autour d’uneDirection Technique forte au service de notrecroissance en garantissant notre approche conseil etun précieux appui à nos collaborateurs.

En devenant la référence incontournable du conseilspécialisé et en fournissant une approchedifférenciante sur l’ensemble du cycle dedéveloppement des produits de nos clients, nousoffrons à nos consultants la capacité de se projeter àlong terme dans un environnement varié et stimulant


EXPÉRIENCE HISTORIQUE DU SECTEUR

PHARMACEUTIQUEExcellente maîtrise des

exigences pour les médicaments à usage humain et vétérinaire

UN ANCRAGE FORT DANS LE SECTEUR DU DISPOSITIF

MÉDICALDispositifs implantables

Electro-médicalSoftware médicaux

Dispositifs combinésDM DIV

DIRECTION TECHNIQUE

Approche conseilEncadrement des consultants

Veille normative & technologique

CULTURE DE FORMATION DES CONSULTANTSFormation continue aux évolutions normatives

Formation spécifique avant intervention

SOLUTIONS DU GROUPE EFORPrésence européenne

Puissance de recrutement

NOTRE VALEUR AJOUTÉE

7 PRÉSENTATION INSTITUTIONNELLE – EFOR-CVO – 2021 – TOUS DROITS RÉSERVÉS

L’EXPÉRIENCE EFOR-CVO

Nos valeurs réunies pour la réalisation de notre ambition commune

EXCELLENCE ENGAGEMENT ESPRIT D’ÉQUIPE DYNAMISME

NOTRE PRÉSENCENos implantations• Paris• Lille• Lyon• Metz• Strasbourg• Belfort• Mulhouse• Nantes• Grenoble

• Val de Reuil• Orléans• Aix-en-Provence• Bordeaux• Toulouse• La-Seyne-sur-Mer• Genève• Bâle• Bruxelles



DISPOSITIFS MÉDICAUX

NOS MÉTIERS

Une expertise dédiée aux industries des Sciences de la Vie

PHARMACEUTIQUE COSMÉTIQUES

BIOTECHNOLOGIES CHIMIE NUTRISANTÉSANTÉ

ANIMALE

DMDIV


NOS MÉTIERS

PHARMACEUTIQUE

COSMÉTIQUE

BIOTECHNOLOGIES

CHIMIE

NUTRISANTÉ

SANTÉ ANIMALE

UNE EXPERTISE DÉDIÉE AUX INDUSTRIES DES SCIENCES DE LA VIE


NOS MÉTIERS

DM ET DMDIV

UNE EXPERTISE DÉDIÉE AUX INDUSTRIES DES SCIENCES DE LA VIE


NOTRE ÉQUIPE

1100 Consultants – Docteurs, Ingénieurs & Pharmaciens

50 Experts Techniques

Différentes formations (biologie, biochimie, mécatronique, etc.)

Différentes spécialisations (Réglementaires, Qualité, Risques, Affaires Clinique, Gestion de projet…)

Différents niveaux d’expertise

Construisent les offres techniques spécifiques correspondant aux besoins de nos clients

Interviennent en support technique à nos consultants dans leurs missions

Assurent la relecture et la validation des livrables

Pilotent les audits et formations internes et externes


Centre de projets

LA DIRECTION TECHNIQUE

DIRECTION TECHNIQUE

Centre d’expertise

Centre de formation

Centre desAudits

50 experts dédiés

10 Pôles métiers


LA DIRECTION TECHNIQUE

R&D Affaires cliniques

Biocompatibilité & toxicologie

Management de la qualité

Qualif équipements

Valid procédésVSI

Affaires réglementaires

IT & digital

Stratégie & excellence

opérationnelle

Affaires scientifiques CQV

Engineering

GaléniqueFormulation

Transfert

Design (Mécanique, Electronique,

Logiciel)Vérification &

validation

Gestion de projet :

Travaux neufs Revamping

Spécialistes de lots :HVAC

EIAProcess &

utilitésBâtiment

Maintenance & fiabilité

Systèmes d’informations

Business analysisAMOA

Gestion de projet

Data Data management,

Data science,RGPD,

Data integrity,Business Intelligence

Digital HealthQualité logiciel,Développement,Gestion de projet

(agile / V)

Industrie 4.0

Supply

Amélioration continue

Expertise lean six sigma

Investigation & évaluation clinique :

Gestion de projet clinique

Rédaction médicale

Soumissions Réglementaires

Monitoring

Biométrie

Biological Risk Assesment

ToxicologicalRisk Assesment

AQSystème

AQFournisseurs

AQOpérationnelle

Contrôle Qualité

Référentiels : 13485/9001/17025/22716/GMP/

ICHQ10

EquipementsProduction,

contrôle

Procédés(Fabrication, nettoyage,

stérilisation, conditionnement,

transport, procédés spéciaux)

Locaux & utilités

Méthodes analytiques &

biologiques

Ingénierie Validation

Exploitation & Maintien

ERPGED

GMAOMES

SCADAPLC

LIMSFichiers excel

AMM

Marquage CE

510k

DIP

Dossiers Export

Vigilance & PMS

CENTRE D’EXPERTISE

www.efor-group.fr www.efor-healthcare.fr www.cvo-europe.com

Agathe ALAGUILLAUME

[email protected]



Présentation de la formation



Accueil des participants



Présentation du formateur

Valérie ADAM

EXPERTISES Qualité Supply Chain Lean Manufacturing Audits fournisseurs et audits internes Expert en amélioration continue Audit règlementaire GMP/GDP/ISO

9001/ISO 22716/ISO 13485 ISO 19011, ISO 22716, ISO 13585, Change

Control, ICH Q9, ICH Q10, Data Integrity,… Gestion des déviations Gestion des SI

EXPÉRIENCES+ de 20 ans d’expérience dans les Sciences de la Vie et la Santé en production et assurance qualité dans les mises sous formes pharmaceutiques aseptiques (injectables) , Laboratoires Lilly France, J&J,, Octapharma, 1 en Chargée Supply Chain Inde et Brésil Ortho-Clinical Diagnostic 2 en Manager Quality IT NOVARTIS 1 en Management des secrétariat CHU Strasbourg Audits fournisseurs industrie pharmaceutique ( SI, Transport, équipements…) FAT/SAT

FONCTIONConsultante séniorAuditeurFormateurConseil

QUALIFICATIONAuditeur Qualifié CVO-EUROPEFormatrice Qualifié



Objectifs de la formation

Rappel des exigences réglementaires et

normatives (FDA, Europe, etc.)

applicables à la validation

1

Comment la validation des systèmes informatisés contribue-t-elle à la maîtrise des risques et à l’amélioration continue ? Quelle stratégie adoptée pour être pragmatique et efficace ?

2

Que se passe-t-il une fois le système validé? Comment maintient-on

son état validé?

3

L

4

La documentation:Quel document pour

quelle étape?



Contenu de la formationV

SI

Points clés et enjeux

La validation

Exploitation – Maintenance

Documentation

QCM, Satisfaction, synthèse



Logistique



N’hésitez pas à poser des questions !



Module 1Points clés et enjeux



Définitions de la Validation

« Établissement de la preuve, en conformité avec les principes desBonnes Pratiques de Fabrication, que la mise en œuvre ou l’utilisationde tout processus, procédure, matériel, matière première, article deconditionnement ou produit, activité ou système, permet réellementd’atteindre les résultats escomptés.»Bonnes Pratiques de Fabrication

ANSM

F.D.A.« Establishing documented evidence which provides a high degree ofassurance that a specific process will consistently produce a productmeeting its predetermined specifications and quality attributes. »Glossary of Computerized System and Software DevelopmentTerminology 01/2006

« Confirmation par l’examen et la fourniture de preuves objectivesque pour les exigences, pour un usage ou application voulue, ont étéremplies. »ISO 9000

« Le processus de validation est un processus qui permet dedéterminer si les exigences et le système ou produit logiciel finauxsatisfont un emploi spécifique visé. »ISO 12 207 “norme internationale « Ingénierie des systèmes et du logiciel -Processus du cycle de vie du logiciel »

ISO

ISO

Exigences accrues sur la partie Data Integrity

De plus en plus d’écarts relevés

La plupart des référentiels y font référence



Système d’Information

Système Informatique vs Système Informatisé : Périmètre de Validation



Pourquoi Valider?

Pour garantir la qualité du produit obtenu (pureté, sûreté, efficacité)

Pour garantir la traçabilité et l’intégrité des données• Bonne décision • Avantage concurrentiel

Pour des raisons économiques Eviter les sinistres:

• Erreur• Malveillance• Accidentelle

Pour respecter la législation



Texte règlementaire Scope

21 CFR part 11 La maîtrise des données électroniques et les Signatures électroniques

ISO 80002-2:2017 Technical Report Boîte à outils

ISO 14971:2019 Dispositifs médicaux — Application de la gestion des risques aux dispositifs médicaux

Annex 11 : Computerised Systems Règles pour maîtrise pour les systèmes informatisés et automatisés

Part III – Site Master file – ICH Q9 (ex annex 20) – ICH Q10

Gestion qualité et approche par les risques

Annex 15 : Qualification Validation Qualification des équipements

Principles of Qualification and Validation in Pharmaceutical Manufacture PIC 1/1996 Guides et conseils au regard des systèmes informatisés

issues d’une coopération entre inspecteurs internationauxPIC – Guide to Inspection of Computer Systems – 1996

PIC/S – PI011-3 - Good Practices for Computerized Systems in Regulated « GXP » Environments - 2007

Les textes de la validation



Les guides Validation

L’ISPE ( International Society for Pharmaceutical Engineering) publie le GAMP depuis de nombreuses années, notamment pour le développement et la validation de systèmes informatisés en contexte GxP.

L’ISO vient de publier un « TechnicalReport » spécifique à la validation des systèmes informatisés utilisés dans le SMQ.



Type de Système

Exigences

Fermé11.10

Validation du système (a) Capacité à détecter les données invalides ou altérées (a) Capacité à générer des copies complètes et fidèles (b) Protection/conservation des enregistrements (c) Limitation d’accès logique aux utilisateurs autorisés (d, g) Audit trail de toutes les actions [critiques] (e) Contrôle des séquences de fonctionnement (f) Maîtrise des interfaces entrantes (h) Vérification de l’expertise des acteurs (développement, utilisation,

maintenance) (i) Documentation d’Ingénierie, Utilisation, Maintenance, Maîtrise des

Modifications (k)

Ouvert11.30

Cryptage des enregistrements Cryptage des signatures

La maîtrise des données électroniques - 21 CFR Part 11



Catégorie Sous-catégorie Exigences

Manuscrite Traditionnelle Pas d’exigence supplémentaire

Table graphique Responsabilisation des personnes (11.10 j)

Manifestation signature (nom légal, date et heure, signification)(11.50)

Lien inviolable signature-enregistrement (11.70)

Électronique Biométrique Signature non utilisable par un tiers (11.100 a-11.200 a2)

Vérification d’identité (11.100 b)

Attestation à la FDA (11.100 c)

Identifiant etmot de passe(sans dispositif)

2 composants d’identification (11.200 a1)

Fraude nécessitant au moins 2 personnes (11.200 a3)

Unicité de la combinaison identifiant/mot de passe (11.300 a)

Péremption et retrait des mots de passe (11.300 b)

Alertes de sécurité (11.300 d)

Identifiant etmot de passe(avec dispositif)

Gestion des pertes (11.300 c)

Tests et vérifications périodiques (11.300 e)

Signatures électroniques – 21 CFR Part 11



Module 2LA VALIDATION: STRATÉGIE ET MISE EN ŒUVRE



Niveau de Maturité en validation: VMM ‘Validation Maturity Model’

InexistantInconscience vis à vis des risques liés aux systèmes.

Attente de remarques des agences pour agir.Culture validation inexistante

1

OptimiséGestion des modifications optimisée.

Indicateurs de performance, mesures, améliorations.La validation est un outil de qualité et de sûreté.Outils mis en place pour supporter la validation

5

GéréLa validation est intégrée dès le début des projets.

La base de la validation sont les specs, RCLa validation est conduite en fonction des risques.

La gestion des évolutions est maîtrisée, mais lourde.

4

InitialPeu de moyens et de ressources allouées (stagiaire).

Quelques personnes sont convaincues de l’importance.Délégation de la validation aux fournisseurs internes ou

externes (info, ingénierie); dossier de «façade».

2

Niveau actuel des agences

ContraintValidation impérative : politique, responsable AQ

MAIS : moyens alloués tardivement.Validation sur le chemin critique, pas d’indépendance.Maintenance de la validation difficile (change control)

3



Entrant à la stratégie de validation

VMP (Validation

Master Plan)

Politique de validation

Catégories : Type DM ou

Qualité ?

Criticité sur utilisation

Méthodes et Outils

Inventaire Nombre /

statut



La politique de validation

DirectionDirection

Approuve le projet :- implique l’équipeou le spécialiste- soutient la validation

Utilisateurs

Responsables

(Process Owner)

(System Owner)

(Subject MatterExpert)

Utilisateurs

Responsables

(Process Owner)

(System Owner)

(Subject MatterExpert)Désigne un

SpécialisteDésigne unSpécialiste

Ressources- financières- personnels

Ressources- financières- personnels

Formationde toutes lespersonnesimpliquées

Formationde toutes lespersonnesimpliquées

Apporte sonsoutien

Impose la Validation



Organiser les validations

Procédures/Processus supports

Lister les systèmes à valider

PDV - VMP

Donne la politique de validation

Définit les principes généraux de validation

Référentiels

Planning à long terme

Explique la stratégie de sélection et de

criticité des systèmesQF, QC/RC, QI, QO, QP

Responsabilités globales



Hors Validation SI Non Critiques

Plan de validation Système 1

Plan de validation système 2

Plan de validation système 3

Stratégiede Validation

Démarche sous responsabilité expert Validation et Assurance Qualité

Identifier les systèmes critiques

Analyse préliminaire des risques Plan directeur de validation

SI Non Critiques SI Critiques

Systèmes Informatisés

Recenser les SI

Organiser la validation



+ Personne ultimement responsable pour le procédé

+ Généralement directeur de l’unité fonctionnelle ou du département qui utilise le système

+ Rôle basé sur la connaissance du procédé plutôt que la position dans l’organisation

Responsabilités selon le GAMP 5 (1/3)

Process Owner : Détenteur du Procédé



+ Personne ultimement responsable pour la disponibilité le support la maintenance d’un système la sécurité des données résidant sur le système

+ Généralement directeur du département responsable du support et de la maintenance du système

+ Rôle basé sur la connaissance du système plutôt que la position dans l’organisation


System Owner : Détenteur du Système



+ Individus avec une expertise dans un domaine particulier

+ Rôle de leader dans la vérification des systèmes automatisés et informatisés

+ Responsabilités des SMEs : Planification et définition des stratégies de vérification Définition des critères d’acceptation Sélection des méthodes de tests appropriées Exécution des tests de vérification Revue des résultats


Subject Matter Expert (SME) : Expert du Domaine



4 catégories selon le GAMP 5

GAMP M4

Logiciel système

1

Produits nonconfigurés

3

Produits configurés

4

Applications Spécifiques

(y compris tous les spécifiques des catégories ci-

contre)

5



Méthodes et Outils

Cycle en V :

La méthode de validation la plus couramment utilisée dans le domaine de la santé est basée sur un modèle dit « en V », étant un modèle d’activités séquentielles ou en cascade; et dont l’objectif initial est de mettre les activités de tests au regard des activités de développement et de planifier.

Scrum :

Une méthode qui tente de percer est la méthode « Scrum », basée sur un modèle dit « Agile », étant un processus itératif et incrémental. L’objectif étant de réduire le risque de déphasage entre le besoin exprimé et l’application réalisée, les dépassements de couts et délais



Le Cycle en V

Vidéo



+ Une liste d’activités pouvant être mise en œuvre afin d’atteindre l’objectif de validation. Liste non exhaustive, à compléter selon les connaissances et expériences

+ Définition d’un « type d’activité » au sens requise ou optionnelle. Full extent : « A réaliser dans son intégralité » : Conduire cette activité telle quelle. Tailor : « Personnalisation » : sélectionner et conduire les parties appropriées de cette

activité. Select : « Au choix » : Sélectionner et mener cette activité le cas échéant

+ Classées selon les principales étapes du « cycle de vie logiciel » avec définitions et/ou explications

+ A mettre en lien avec des procédures

La boite à outils

.

Cf ISO TR 80002



Activités Requis ou non Activités Commentaires

Phase : Define Full extent Process requirements definition.The output from this activity can be documented in a process flow schematic or requirement statements

1er point : Importance de la définition des besoins, au niveau du processus d'utilisation (pas seult fonctionnel) : donc identifier les aspects réglementaires, les aspects activités pilotées/ contrôlées par le logiciel, activités hors contrôle logiciel et activités liées (montantes / descendantes)

Phase : Define Full extent

Process failure risk analysis.The results of risk analysis should be clearly documented because such results are valuable decision drivers for selecting tools from the toolbox and for justifying the level of effort applied to the validation activities

Thèmes identifiés: - Sécurité du dispositif / santé du patient & efficacité : préjudice direct ou indirect aux

patients , et personnel de fabrication- Système qualité et risques réglementaires : non conformes aux requis

réglementaires si pertes de données, type CAPA, plaintes, historiques..., - risques liés à l'environnement dans lequel le système est utilisé : physique et virtuel.

Phase : Define Full extent

Validation planning : Validation planning is performed in two phases:— during the develop-define phase to define the level of detail and effort expected (…);— later, during the implementation phase, The output from validation planning is a plan that describes the activities that will be performed (….)

Note : Dans le GAMP, la planification se fait en 2 fois, via 2 documents distincts : le plan directeur de validation et le plan de validation système.Et on peut ne pas faire de plan de validation pour les systèmes simples (car VMP fait le lien). Ici on parle de planning de validation « itératif », sur la base du résultat de l’analyse de risques.

Phase : Define Full extent Risk management planning Plan pour choisir la méthode d'analyse de risques à utiliser pour le système.

Phase : Define / Implement

Full extentIdentification of risk control measures within the manufacturing or business process

Identification des mesures de contrôles des risques et surveillance continue pour s’assurer de l’efficacité des moyens de mesures.

Phase : Implement

Full extent Analysis of software failure Analyse de risques fonctionnels.

Présentation de la « boite à outils » ISO 80002 / Ingénierie




Phase : Define (Tailor)

Intended use :Elements of intended use:— software purpose and intent;— software use requirements;— software requirements.

Donne des questions clés : * Use : La définition de l'utilisation du soft doit répondre à : Quoi, pourquoi, comment, qui, où et quand. Et donc par rapport au processus dans lequel il sera utilisé.* Reg : une défaillance affecterai la sécurité ou qualité du DM ? le soft exécute une activité demandé par les AR ?...* limites du soft : Quel rôle joue le soft dans le process? limite avec autres systèmes : ITF ? Vient compléter la ligne « Obligatoire » sur l’expression des besoins.

Phase : Define (Select) Formal software requirements reviewRevue et approbation des spécifications fonctionnelles du système au regard des besoins

exprimés. En fonction de l’approche choisie (traditionnelle, Agile…) cela peut être réalisé via des revues documentaires séquencées ou en meeting, …

Phase : Define (Select)Software development life-cycle model choice

Uniquement pour les systèmes fait à façon (correspond à cat 5 du GAMP). Le choix du modèle de développement pourrait être par exemple méthode Agile. Peu développé dans GAMP.

Phase : Implement (Select)Software architecturedocumentation and review

La documentation d’architecture permet de vérifier l’exactitude de la structure des éléments, l’exhaustivité et leur capacité exécuter des fonctions logicielles.

Phase : Implement (Select) Design specificationLes spécifications de conception documentent les composants, les structures de données, les

formats d’entrée et de sortie, la description des interfaces…

Phase : Implement (Select) Development and design review Définit la revue de conception. Idem GAMP

Phase : Implement (Select) Code review or code verification Définit la revue de code. Idem GAMP

Phase : Implement(Select)

Traceability analysis Matrice de traçabilité depuis les exigences, risques, tests, moyens de mesures…

Phase : Implement(Select)

Vendor audit Définit l’audit du fournisseur de logiciels

Présentation de la « boite à outils » ISO TR 80002 / Ingénierie




Dev Phase : Test (Select) Test planning

la planification des tests est ici mise à part pour faire apparaitre la notion de niveau de test :, tests unitaires, tests d'intégration (on retrouve la terminologie "IS") test utilisateurs, de charge, tests opérationnels. Et rappel qu’on doit avoir une approche basée sur l’analyse de risques pour définir quels tests doivent être mis en œuvre et suivis.

Dev Phase : Test (Select) Unit testing Le test unitaire : exécution d’un composant dans son environnement de développement

Dev Phase : Test (Select) Integration testingLe test d’intégration : s’assurer du fonctionnement de l’assemblage des éléments du logiciel, des interactions avec le matériel, des interactions entre les modules.

Dev Phase : Test (Select) Software system testingLe test système : vérifie que le système fonctionne tel que défini dans les spécifications, dans sa globalité (avec les interfaces, avec l’administration, et s’assurer de l’intégrité des données)

Dev Phase : Test (Select) Use case testingLe test utilisateur, (aussi appelé test d’acceptation) : évaluer par une simulation de flux métier, dans un environnement réel, la conformité des résultats obtenus. Ce sont des tests dits « boite noire » pour vérifier que le système donne satisfaction par rapport aux exigences métier.

Dev Phase : Test (Select) Interface testing Test d’interface entre les applications logicielles, en prenant en compte l’intégralité du chemin.

Dev Phase : Test (Select) Regression testing Test ré exécuté après modification d’une fonction afin de détecter les erreurs potentielles

Dev Phase : Test (Select) Vendor-supplied test suiteTest fournis par le fournisseur pour vérifier les fonctionnalités. A challenger quand à l’exhaustivité, les risques identifiés et l’adéquation des données et conditions de tests.

Dev Phase : Test (Select) Normal case testing Test en conditions usuelles d’utilisation

Dev Phase : Test (Select) Robustness testingLes tests de robustesse doivent démontrer que le système réagit correctement lors d’entrées invalides, aux limites ou imprévues, et les conditions anormales d’utilisation.

Dev Phase : Test (Select) Data verification Vérification des données : activités réalisées pour confirmer l’exactitude des données, suite à migration, ou conversion de données.

Présentation de la « boite à outils » ISO TR 80002 / Testing Project




Dev Phase : Deploy (Select) Installation qualificationVérification de l’installation et de la configuration conformément à des instructions d’installation documentées

Dev Phase : Deploy (Select) Operational qualificationVérification d’un fonctionnement cohérent dans les limites et les tolérances établies, du processus et des systèmes associés

Dev Phase : Deploy (Select) Performance qualification Vérification de l’efficacité et de la reproductibilité du processus

Dev Phase : Deploy (Select) Final acceptance testingTest de réception final : fait référence aux tests appliqués au système juste avant le déploiement. Appelée aussi test « Go-Live »

Dev Phase : Deploy (Select) User procedure review Revue des procédures et instructions d’utilisation rédigées par les utilisateurs

Dev Phase : Deploy (Select)Internal training for theapplication

Activités de formation documentées spécifiques au système

Dev Phase : Deploy (Select) Operator certificationCertification des opérateurs : confirmation que les personnes formées présentent des preuves de compétence

Présentation de la « boite à outils » ISO TR 80002 / Validation



Identifier périmètre de validation

Testez-vous!



Système d’Information

Système Informatique vs Système Informatisé : Périmètre de Validation



Organiser la validation

Plan de Validation

Référentiel de la

validation

Référentiel

Ingénierie du

Logiciel

PDV

SBU Plan Projet

(Organisation, Planning, …)

PréparationVérifier

1. La démarche de développement du logiciel (cycle, maîtrise, …)

2. Les exigences du projet3. L’organisation mise en place4. Le domaine d’application du système

Puis

5. Définir les responsabilités6. Identifier le « Périmètre »7. Construire la stratégie8. Identifier la démarche et les livrables

Pour

9. Rédiger le plan de validation



Les besoins utilisateurs (SBU-URS)



Ingénierie Testing Projet Validation / Client

Spécification Besoins Utilisateurs (SBU ou URS)

Spécification Fonctionnelles (SF)

Développement / Configuration

Analyse de Risques (AR)

Revue de Conception (RC)

Qualification d’Installation (QI)Spécification de conception et

Technique (ST ou SD)

Conception technique et fonctionnelle

Tests Acceptation Client

Tests de recetteQualification

Opérationnelle (QO)

Tests Intégration

Qualification de Performance (QP)

Tests Unitaires / Composants / Code

Méthodologie de validation utilisée dans le domaine santé : le cycle en V



Pourquoi a t’on besoin des URS?

53



Spécification

Spécifications FonctionnellesDécrivent les fonctions à assurer par les

équipements, les logiciels et les systèmes

Spécifications TechniquesDécrivent les contraintes et les environnements dans

lesquels doivent évoluer les équipements, les logiciels et les systèmes

Décrivent ce que l’équipement ou le système est censé faire, et contenant de ce fait au moins un jeu

de critères ou conditions devant être satisfaits.Spécifications de Besoins

Quoi?

Comment?

Comment?



+ Identifier les raisons de la mise en place d’une nouvelle application

+ Identifier chaque étape du processus gérée via le système informatisé à valider, et les données critiques gérées à cette étape.

+ Identifier si d’autres systèmes informatisés gèrent déjà en partie cette étape du processus, ou reçoivent les données sortantes du processus, ou bien sont à l’origine des données entrantes.

Equipe pluridisciplinaire ( expert, utilisateur, qualité, IT, etc……)

….

Ce qui est souhaité au regard du processus : Quoi vs Pourquoi ?

Les besoins



L’expression des besoins / Le cahier des charges

Règles de rédaction d’un cahier des charges :

+ C’est le document qui explique ce dont on a besoin, il doit donc être : clair, sans ambigüité, exhaustif (tout ce qu’on souhaite et parfois ce qu’on ne veut pas si c’est

important) Les exigences numérotées pour simplifier la traçabilité

URS nécessaire pour rédiger le cahier des chargesCahier des charges nécessaire pour auditer le fournisseur



L’expression des besoins / Le cahier des charges

+ Contenu d’un cahier des charges :

Les précisions relatives au périmètre d’utilisation afin de faire le lien avec le cadre réglementaire associé

Composition / Description du système souhaité (équipements / modules; système informatique; imprimantes…. )

Le descriptif sur les interactions avec les autres systèmes du Laboratoire, les flux d’échanges et le type de données gérées par le système

Exigences de performances techniques des équipements (liées aux exigences réglementaires par exemple)

Exigences de performances réglementaires pour la gestion des accès / sécurité, des données, la gestion des modifications / Audit

Besoins sur la gestion des données de références, des méthodes, des algorithmes et formules de calculs…

Besoins de reprise de l’existant d’un système précédent

Besoins liés au support du fournisseur, et contrat de maintenance

Besoins liés à la formation du personnel

Besoins en documentation



Extrait de quelques exigences utilisateurs



Expression des besoins : Points clés abordés

Savoir exprimer les besoins par rapport au processus d’utilisation souhaité

Exhaustivité

Etre précis sur le besoin, sans détailler la solution

Base de la validation



Sélection du fournisseur



Qui doit-on auditer ?

Fournisseurs actuels non encore audités

Fournisseurs pressentisFournisseurs internesFournisseurs externes

+ Vendeurs de Solutions

+ Vendeurs de Logiciels

+ Développeurs

+ Intégrateurs

+ Infogérants

+ Hébergeurs

+ Fournisseur d’IAAS/PAAS/SAAS

+ Service informatique

+ Étude/développement

+ exploitation

+ Infrastructure Informatique

+ Maintenance (équipement)

+ …



Objectifs de l’audit

+ Connaître le fournisseur

+ Avoir confiance dans le fournisseur dans le produit/service/prestation acheté/fourni

+ Développer un partenariat

+ Ajuster son comportement de validation en fonction de la confiance



Périmètre de l’audit

+ Vérifier que le fournisseur a placé son organisation sous assurance qualité

+ Vérifier que le système ou logiciel est, ou sera construit suivant cette organisation

+ Vérifier que le système ou logiciel est, ou sera développé en suivant des bonnes pratiques de développement

+ Vérifier que le service, la prestation est, ou sera délivrée dans le respect des bonnes pratiques informatiques

+ Enfin l’audit permet aussi de vérifier sur le terrain comment certains besoins et exigences sont ou seront couverts : exemple comment est gérée la documentation du produit



Quand auditer son fournisseur ?

+ La certification du fournisseur est un plus, mais ne peut se substituer à la qualification et aux audits routine .

Audit de sélection/Qualification

• Avant toute collaboration

• Vérifier les pratiques du fournisseur, que l’on peut travailler avec lui sans accroître le risque

Audit routine

• Pendant l’exécution du contrat : périodiquement

• Maîtriser le fournisseur

Audit for cause

• Suite à dysfonctionnement grave

• Vérification terrain



Comprendre de que l’on achète, pour adapter l’audit

Axes d’analyse : Perte de contrôle sur : le datacenter, les services, les données, réseau externe (encryptage), différentes approches de qualification des hébergeurs…



Editeur de logiciel

Intégrateur

IAAS avec hébergement

PAAS avec Hébergement SAAS

Qualité logicielQualité du

support/maintenance

Qualité de la documentation projet, qualité de l’installation,

du paramétrage

Disponibilité/Continuité des l’infrastructures

physiques et virtualisées,

Data center sécurisé

Disponibilité/continuité de la plateforme des infrastructures

physiques et logiciels, DC sécurisé

Disponibilité et continuité du service

applicatifIntégrité des données

Comprendre ce que l’on achète, pour adapter l’audit de sélection

« On premise » sur site (en

intene)

Audit Méthodologie de développement/ capacité à corriger et améliorer le

logiciel

Audit Méthodologie projet/maintenance &

supportAudit Orienté qualité de

service sécurité, traçabilité des changements,

incidents,

Audit vérifiant la qualité du Service, capacité à maintenir le logiciel en

conditions opérationnelles et à

protéger les données

« outsourcing »



+ Certaines exigences réglementaires et métier doivent être déclinées en instructions de travail pour le fournisseur

+ Le plan d’action de l’audit de qualification peut être repris dans le contrat

+ Le droit d’auditer périodiquement le fournisseur

+ Les niveaux de service exigés.

+ La réversibilité en fin de contrat

+ Le support du fournisseur lors des inspections réglementaires ou audits

Externalisation « Outsourcing » points à intégrer au contrat

+ L’audit de qualification doit être réalisé en amont de toute collaboration, avant la signature du contrat si possible



Tests fournisseurs et Tests de validation

+ Le fournisseur doit tester le matériel et le logiciel / programme pendant son développement et avant la livraison !

+ Parfois, celui-ci «vend» ses tests, sous l’appellation de « dossier de validation » !

+ Ces tests ne sont pas des tests de validation mais des tests de vérification !

La validation a pour but de démontrer que le système correspondaux besoins des utilisateurs et que le système est fiable.



Les tests au cours d’un projet et la QO

Souvent, il y a confusion entre les tests :

d’ingénierie en conception, développement et réalisation de système / logiciel / programme (tests unitaires, tests de module, tests d’intégration)

de réception / d’acceptation (de recette) : UAT

de QO

Ces tests ne visent pas à démontrer la même chose.• Tests d’ingénierie : démontrent que le système est conforme à la conception et au développement• Tests de réception : démontrent la conformité aux spécifications• Tests de QO : démontrent le bon fonctionnement par rapport aux exigences utilisateurs et la maîtrise des risques liés à la qualité produit, la sécurité patient et l’intégrité des données. La QO prend aussi en compte la spécificité de l’entreprise : organisation, types de produits fabriqués, procédures ...



Recevabilité des tests

+ Les tests à réaliser en validation sont dictés par :

Périmètre réglementaire Périmètre fonctionnel et

technique Stratégie de validation

• Analyse de Risques• Plan de Validation

+ La recevabilité des tests de validation est liée à :

Processus qualité• Approbation des protocoles, des

rapports• Gestion (suivi, correction) des

écarts• Maîtrise des environnements

Modalités de gestion des données brutes

• Signatures, Copies d’écran• Multi exécutions

Couverture du périmètre Respect de la stratégie Adaptation au contexte de

l’entreprise (surtout en QI et QP)



Définition des Tests Fournisseurs

Rédaction : Utilisateurs ou FournisseursApprobation : Utilisateurs et Fournisseurs

Réunion avec les fournisseurs pour connaître les tests qu’ils prévoient de

réaliser et comment ils les documentent

Adaptation des tests fournisseurs pour les rendre acceptables et utilisables

d’un point de vue réglementaire

Rédaction des protocoles fournisseurs pour intégrer les tests fournisseurs dans le programme de validation

Utilisateurs et Fournisseurs

Utilisateurs et Fournisseurs



Définition des Tests Utilisateurs

Analyse d’écarts

Tests Utilisateurs Complémentaires+ Vérification des tests fournisseurs

pour les valider

Tests à réaliser suivant AR et AC

(Protocoles Utilisateurs)

Tests fournisseurs (Protocoles

Fournisseurs)



+ Avoir identifié le niveau qualité du fournisseur Pour définir si une approche « Validation Intégrée » peut être mise en place Selon quel modèle de développement

+ Avoir discuté concrètement des modalités d’acceptation / recevabilité des tests d’ingénierie Processus qualité

• Approbation des protocoles, des rapports• Gestion (suivi, correction) des écarts• Maîtrise des environnements

Modalités de gestion des données brutes• Signatures, Copies d’écran• Multi exécutions

Couverture du périmètre Respect de la stratégie Adaptation au contexte de l’entreprise

En sortie d’Audit



Qualification des Fournisseurs (QF) : Points clés abordés

Enjeux forts pour le partage des tâches de validation

Bien se préparer pour être efficace

Importance du suivi d’audit

L’implication du fournisseur : « Les bonnes personnes aux bons endroits »



La validation



Objectifs de l’Analyse de Risques en Validation

Identifier , Analyser et évaluer les risques liés à la sécurité des patients, la qualité Produit et l’intégrité des données.

Afin de s’assurer que les solutions mises en places sont efficaces et pour définir la stratégie de test : Les tests de qualification doivent être concentrés sur les

fonctions à risques élevé. Prévoir de capitaliser sur les tests d’intégration et les tests

système si possible

l’analyse de risques

INDISPENSABLE pour la stratégie de tests !















Tests Intégration






Loi de Murphy 1949

ce qui reste optimiste pour les logiciels et programmes

+ Logiciel : Défaillances techniques ...+ Matériel : Panne, indisponibilité ...+ Environnement : Perturbation, contamination ...+ Équipement : Défaut d’étalonnage ...+ Données : Données techniques erronées ...+ Personnel : Erreurs, oublis, accès ...

Si un ennui a la moindre chance de se produire,

il se produira



L’Analyse de Risques en pratique : Se poser des questions

Que peut il se passer quand je réalise une action, dans des conditions habituelles ou inhabituelles ?

Quel impact sur mon produit ou sur la décision prise sur le produit lorsque j’utilise une fonction avec un défaut ?

Pourquoi cela pourrait il se produire ?

Nécessite de connaitre le cadre et le processus d’utilisation, la criticité de la donnée traitée.

Permet de définir le risque.

Ne pas minimiser en prenant en compte des solutions techniques ou organisationnelles qui ne sont pas déjà en place.

Permet de définir la conséquence

Nécessite de connaitre la solution (lecture des spécifications fonctionnelles et techniques)

Permet de définir la ou les causes



Pré-requis au déroulement d’une analyse de risques

Comprendre

le

systèmeÉtape 1Événement

déclencheur Étape nRésultat étape 1

Résultat étape n

Interface (5M : Matière, Main d’œuvre, Mode opératoire, Milieu, Matériel)

Interface (5M : Matière, Main d’œuvre, Mode opératoire, Milieu, Matériel)

ProcessusProcessus

FonctionN° 1

FonctionN° 2

FonctionN° ...

FonctionN° n

Composants

Supporte



L’Analyse de Risques en pratique :

Quelque soit la méthodologie choisie, définir une échelle de cotation pour les différents critères d’analyse.

Utilisation d’une matrice

d’aversion pour combiner

les critères d’analyse



Exemple de méthode

L'AMDEC étant une méthode prédictive, elle repose fortement sur l'expérience.

Il est donc nécessaire de faire appel à des expériences d'horizons divers afin de neutraliser l'aspect subjectif des

analyses.



Préparation

• Constitution de l’équipe de travail• Définition périmètre & portée de l'analyse de risques

Analyse Fonctionnelle

• Découpage fonctionnel du système étudié en sous-fonctions / composants• Structure du système & modélisation

Identification

• Etude qualitative des modes de défaillances• Identification des défaillances, causes, effets, moyens de détections existants

Valorisation

• Etude quantitative des modes de défaillances / étude de criticité• Examen des modes de détection & cotation de la criticité (S x O x D) Hiérarchisation

Mesures

• Recherche & identification des actions correctives & préventives• Suivi des CAPAs & réévaluation de la criticité

83

AMDEC - Méthode

AC

CE

PT

AT

IO

N D

U R

ISQ

UE



AMDEC : Trois critères de cotation

La Sévérité (ou gravité) des effets, impacts ou conséquences de la défaillance.

L’Occurrence (ou la probabilité d’apparition) des causes.

La Détectabilité (ou la probabilité de détection) de préférence des causes.

L’Indice de criticité est le produit des notes des 3 critères :

IPR = S x O x

D Permet une CLASSIFICATION des risques donc une PRIORISATION



AMDEC : Déroulement

En s’appuyant sur l’analyse fonctionnelle ou sur la modélisation on recherche :

Les défaillances potentielles Les causes Les effets Les moyens de détection

Identification

• Etude qualitative des modes de défaillance• Identification des défaillances, causes, effets, moyens de détections

existants

Valorisation

• Etude quantitative des modes de défaillance / étude de criticité• Examen des modes de détection & cotation de la criticité (S x O x D)

Hiérarchisation



AMDEC : Détermination des modes de défaillance

Mode de

Défaillance

Conséquence(s) /

Effet(s)Cause(s)

Moyen(s) de

détectionS O D

Description littérale

et précise du

système et sous-

systèmes

Issue de l’analyse

fonctionnelle

Description littérale et

précise de la

conséquence de ce

mode de défaillance

(ex. santé publique,

panne, produit non

conforme…)


précise de la 1ère cause

du mode de défaillance

étudié


précise du moyen de

détection du mode de

défaillance, déjà en

placeDescription littérale et

précise de la 2ième cause

….

Que peut-il arriver au produit, au composant ou dans l’étape pour que la fonction ne soit pas assurée ?

Quels dangers veut-on éviter ?

Quel est le composant,

l’élément ou l’action qui

engendre / fait apparaître la

défaillance ?

Comment il engendre / fait

apparaître la défaillance ?

Que se passe-t-il lorsque la défaillance est apparue ?

Quelles sont les conséquences ?

Quelles sont les incidences sur la fonction ?

Quels sont les moyens en

place permettant de détecter

la défaillance?

Quels sont nos éléments de

maîtrise du risque ?



Acceptation du risque (ISO 14971)



System Activities Functional specification Cause Risk ScenarioRiskType

ImpactProbability

Severity

Risk Class

Detectability

Risk Priority

Test level

SAP / LIMS

QAC00_01 SamplingRequestQAC01_01 SamplingRequest

Etiquettes : Demandes d'analyses (création manuelle DA principale ) et DA automatique

(car DA créée avec donnée manquante : atelier demandeur) ou à un atelier non adéquat (car erreur sur la sélection du demandeur, modification erronée

Etiquettes d'identification des prélèvements non générées)

GxP

Pas d'édition d'étiquette possible dans les temps ou dans un autre atelier (Perte de temps)

Medium Low Low High Low

SAP

QAC00_03 Testing

Inspection lot _Change QA02 and QP02règle de gestion : Inspection lot supprimables ? Modifiables ?

ITFInspection lot supprimées ou modifiées après transfert

Inconsistency between Inspection lot SAP and LIMS Analytical request.

GxPTraçabilité faussée, Décision prise sur la base de données incomplètes

Medium Medium Medium Medium Medium

LIMS /SAP

QAC00_03 Testing (RM)QAC01_05 Testing (IPC / FP)

Result integration through IEQAC30_LIM_003

ITF Error (transcodification or technical error)Inconsistency between Analytical status into LIMS and Inspection lot status into SAP

GxP Error on release decision Medium High High Medium High

SAP

QAC01_05 Testing

Inspection Lot in ProductionWorklist QA33 _ Record results for In-process parametersCO60/QE01

Display all inspection lot including those from LIMS. Change on result recorded from LIMS by SAP function / Result from ITF not locked. Change on status recorded.

Inconsistency between Analytical status into LIMS and Inspection lot status into SAP

GxP Error on release decision Medium High High Low High

SAP

QAC00_04 Release Workflow management

Quality InspectionQA17 Job planning for auto usage decision

Error on Programme RQEVAI30 (lancement manuel possible via QA17, sinon routine), soit un pb ordonnancement, soit manque les données ITF LIMS

Prise de décision automatique par SAP non réalisée

Business Waste of time Medium Low Low Medium Low

SAP



Error on Programme RQEVAI30 (lancement manuel possible via QA17, sinon routine),

Prise de décision automatique par SAP faite sur des produits non autorisés (PF et PA)

GxP Non respect des flux définis Medium Medium Medium Low High

SAP



Error on Programme RQEVAI30 (lancement manuel possible via QA17, sinon routine),Pb ITF LIMS

Prise de décision automatique par SAP se fait même si toutes les caractéristiques ne sont pas conformes

GxPError on release decision. Batch accepted with OOS

Medium High High Low High

SAP


Quality Inspection

Error on settings parameters (Z9 devenu Z8xx vient de 08 changes batch status from Unrestricted use to Quality Inspection and allows UD with A1

Inspection lot de type Z9 ne change pas le statut du lot et ne bloque pas le stock

GxPLe lot reste utilisable et /ou déphasage avec le stock physique

Medium High High Medium High

SAP

QAC03_05 Batch review

Usage Decision for API and reworkUEQAC30_10_007 and QA32 UD code

Error on check performed on deviation or on flag ok for release. (Because error on notification creation, or notification is not updated on criticity and status)

Notification missing or erroneous on the batch

GxPError on release decision. Batch accepted with open deviation

Medium High High Low High

AR SAP



Détermination des éléments à qualifier (AR) : Points clés abordés

Se focaliser sur la réglementation mais sans oublier les exigences et les risques techniques

Importance d’une bonne modélisation du périmètre

Etre systématique, exhaustif en restant pertinent

Ajuster son effort



La validation















Tests Intégration






Définitions – Revue de Conception

Qualification de conception(Eudralex volume 4 BPF,

Annexe 15 Qualification et Validation)

Development and design review is a review conducted to evaluate the progress, technical adequacy and risk resolution of the selected design approach for one or more configuration items.

Documented verification that a system is installed according to written and pre-approved specifications.

Development and design review

(ISO/TR 80002-2:2017 Technical Report Validation of software for medical

device quality systems)

Design Review(GAMP® Good Practice Guide:

Appendix 21 A Risk-Based Approach to Testing of GxP Systems)

Vérification documentée que la conception proposée desinstallations, systèmes et équipements convient aux usagesauxquels ils sont destinés.



+ La communication avec le fournisseur / Intégrateur : Revue formelle des documents d’ingénierie

+ Livrable : La matrice de traçabilité URS / FS

+ Et pour les spécifiques : La revue de code.

La revue de conception

E4

E3

E2

E1

F6

F5

F4

F3

F2

F1

Exigence non

spécifiéeFonction ne

correspondant à aucune exigence

Dev Phase : Implement



Exemple RC



Revue de conception (RC - QC) : Points clés abordés

La RC est souvent mal comprise

Bien utilisée, la RC est un outil formidablement puissant

La RC impose un certain niveau de maturité (présence de spécifications)



La validation: la qualification d'Installation (QI)

Vérification documentée que les installations, systèmes et équipements, tels qu’ils ont été installés ou modifiés, sont conformes à la conception approuvée et aux recommandations du fabricant.

Qualification de l'installation (Eudralex volume 4 BPF,


Installation qualification means establishing confidence that the software is installed and functioning according to the documented installation instructions.

Documented verification that a system is installed according to written and pre-approved specifications.

Installation Qualification (ISO/TR 80002-2:2017 Technical Report

Validation of software for medicaldevice quality systems)

Installation Qualification (GAMP® Good Practice Guide:
















Tests Intégration






QI - Objectifs

Vérification que :

chaque composant du système est correctement installé

chaque composant du système pourra être correctement désinstallé et réinstallé si nécessaire

les capacités statiques sont conformes aux :

• spécifications techniques du fournisseur ;• exigences de l’utilisateur ; • à la réglementation.

Dev Phase : Deploy



Installation et Qualification+ QI = vérifier l’installation d’un système

+ QI différent de documenter l’installation réaliser l’installation

Bien souvent, on confond la gestion de la configuration (identification des composants, traçabilité ...) avec la QI. La QI se limite à s’assurer que tous les composants qui DEVAIENT être installés (et uniquement ceux-ci), le sont effectivement, selon une procédure appropriée (vérification statique).En outre, elle consiste, à l’aide de tests appropriés, à vérifier que le composant unitaire fonctionne correctement (par exemple, qu’une imprimante imprime toutes les lignes d’un texte standard).



Pré-requis de la QI

Connaissance de la structure du système

Une connaissance de la structure du système livré est nécessaire (vision boîte grise à boîte blanche si exigence de maintenabilité), pour permettre de répondre aux questions :

Que me livre-t-on ?

Y a-t-il des vérifications à prévoir lors de chaque installation / réinstallations ?

Comment maintenir la conformité après l’installation ?

+ Schémas d’infrastructure

+ Procédure d’installation

+ Liste des composants

+ Recommandations fournisseurs

+ Descriptif de configuration matérielle et logicielle

+ ...



+ Vérifier la conformité de la livraison par rapport à la commande

+ Vérifier la documentation fournisseur

+ Vérifier la conformité du logiciel / programme livré par rapport aux UAT (i.e., logiciel / programme livré = logiciel / programme testé par le fournisseur)

+ Vérifier les procédures d’installation

+ Vérifier qu’un document prouve que l’installation de tous les éléments critiques a été réalisée selon une procédure et a été vérifiée

Contenu de la QI (1/2)



+ Vérifier que tous les éléments du système sont identifiés et enregistrés de façon formelle et systématique

+ Vérifier les procédures d’exploitation (changement d’élément …)

+ Vérifier les tests réalisés par le fournisseur

+ Vérifier les procédures de maintenance

Installation / désinstallation d’éléments

Modification de la configuration

Ajout d’éléments

Mise sous route, Arrêt de jobs

Sauvegarde / restauration

Auto test et diagnostics

Contenu de la QI (2/2)



ENVIRONNEMENTDE

VALIDATION

QIQI

ENVIRONNEMENTDE

PRODUCTION

« Démarrage »

Avant mise en exploitation Après mise en exploitation

ProblématiqueQI environnement de Validation / QI environnement de production

Ordonnancement de la QI pour un Système Informatisé



Qualification d’Installation (QI) : Points clés abordés

La QI n’est pas de l’installation

Penser aux différents environnements utilisés dans le projet

Matériel + Logiciel des ressources dédiées au système

Les ressources communes font l’objet de dossiers de validation dédiés

Première question à laquelle la QI doit répondre : Est-ce que j’ai toute la documentation qui prouve que le système a été installé correctement ?

Deuxième question à laquelle la QI doit répondre : Est-ce que j’ai tous les éléments nécessaires au maintien du système en bon état de marche ?



La validation : Qualification Opérationnelle (QO)

Vérification documentée que les installations, systèmes et équipements, tels qu’ils ont été installés ou modifiés, fonctionnent comme prévu sur toute la gamme d’exploitation

Qualification Opérationnelle(Eudralex volume 4 BPF,


Operational qualification establishes confidence that the manufacturing process and associated systems are capable of consistently operating within established limits and tolerances.

Documented verification that a system operates according to written and pre-approved specifications throughout specified operating ranges.

Operational Qualification (ISO/TR 80002-2:2017 Technical Report


Operational Qualification (GAMP® Good Practice Guide:
















Tests Intégration






QO : Qualification Opérationnelle - Objectifs

Vérifier que le système est apte à fonctionner correctement :

par des tests de fonctionnement du système (tests dynamiques)

vérification de la capabilité du système, du logiciel ...

recherche des erreurs et des anomalies en simulant défauts, stress, conditions limites ...

Dev Phase : Deploy

Vérification desfonctions du système

Vérifications de l’administration du système

Gestion des droits et ParamétrageQO



+ Tester avec l'intention de trouver des erreurs

+ Les spécifications de tests doivent inclure les résultats attendus

+ Les résultats de chaque test doivent être conservés

+ Les résultats de chaque test doivent être examinés et analysés

+ Le test doit montrer que le système fait ce qu'il est censé faire

+ Le test doit montrer que le système ne fait pas ce qu'il n'est pas censé faire

Savoir tester



La fonction f est définie dans les spécifications.

Le test mesure l’écart entre le résultat attendu r, et le résultat obtenu r ’ selon une sollicitation prédéfinie e.

L’art du test consiste à choisir de façon judicieuse lesfonctions pertinentes à tester, avec des entréesreprésentatives.

Identifier les tests

Fonction àQualifier

Domained’entrée

e f(e)=r

Résultats

r



+ Tester les fonctionnalités et la conformité aux spécifications (Nominal)

+ Tester les conditions d’erreur (Défaillance)

+ Tester aux limites du système, des champs (Limite)

+ Tester les capacités dans les cas les plus défavorables (Stress / Worst Case)

+ Tester les coupures (Stress / Défaillance)

Les différents types de tests



Types de test

Ce test vérifie lefonctionnement standarddu système. Il estdémontre que le systèmefait bien ce qu’il est censéfaire.

Ce test vérifie la réponse dusystème aux conditionsanormales de fonctionnement.Il démontre que le système nefait pas ce qu’il n’est pascensé faire.

Test NominalTest Nominal Test en défaillanceTest en défaillance

Ce test vérifie le fonctionnement aux limitesextrêmes de fonctionnement standard. Ildémontre que la saisie des données critiques nepeut être faite que dans les intervalles prévuspar les spécifications et que le systèmefonctionne correctement dans les cas les plusdéfavorables de fonctionnement (worst case).

Test aux limitesTest aux limites

Stress : le test de stress démontre que le systèmefonctionne correctement lorsqu’il est soumis à descontraintes élevées.

Charge : le test de charge démontre que le systèmefonctionne correctement lorsqu’il est soumis à un volumede données et de traitements élevé (cas de l’acquisition oudu stockage de données).



+ Vérifier que toutes les fonctions ont été testées comme définit dans le protocole

+ Prouver que toutes les fonctions ont été testées en fonction de leur criticité

+ Retrouver facilement les tests d’une fonction particulière si nécessaire

Processus de Traçabilité



Ordonnancement de la QO – Systèmes informatisés

ENVIRONNEMENTDE

PRODUCTION

ENVIRONNEMENTDE

VALIDATION

« Démarrage »

QO

Avant mise en exploitation Après mise en exploitation

QIQI

Conditions de réalisation les plusproches possibles des futuresconditions réelles de production



Qualification Opérationnelle (QO) : Points clés abordés

On ne peut pas se contenter de tests nominaux en QO

Penser aux fonctions

Utilisateur

Administrateur

Conditions les plus proches possibles de la réalité

Travail conséquent !



La validation: Qualification de Performance (QP)

Vérification documentée que les installations, systèmes et équipements, tels qu’ils ont été agencés, sont en mesure de fonctionner de manière efficace et reproductible, sur la base de la méthode opérationnelle approuvée et de la spécification du produit

Qualification de Performance(Eudralex volume 4 BPF,


Operational qualification establishes confidence that the manufacturing process and associated systems are capable of consistently operating within established limits and tolerances.

Documented verification that a system is capable of performing the activities of the processes it is required to perform, according to written and pre-approved specifications, within the scope of the business process and operating environment.

Performance Qualification (ISO/TR 80002-2:2017 Technical Report


Performance Qualification (GAMP® Good Practice Guide:
















Tests Intégration






Objectifs de la QP

+ La QP est basée sur les URS

+ Les éléments vérifiés sont des objectifs, identifiés en terme de satisfaction client

+ Démontrer en utilisation réelle, que le système n'affecte pas défavorablement la qualité des produits

+ Vérification des performances et de l'efficacité du système en conditions réelles

+ Vérification que le système fonctionne régulièrement dans le temps (stabilité et répétabilité)



+ Le protocole de QP va chercher à démontrer qu’un système reste fiable dans la durée.

+ Utilisation :

des indicateurs (défauts constatés, durée d’indisponibilité ...)

des procédures de vérification systématiques (double contrôle, systèmes parallèles)

des procédures de vérification par échantillonnage

un système de suivi en particulier

La QP n’a de sens que pour une activité représentative de la production.

La fiabilité du système



QP = 2 ou 3 étapes

QP

QPA Vérifier que le systèmeest prêt pour la mise en prod :

Etapes de validation Formations Droits d’accès Documentation Données

QPI Indicateurs après la mise en prod

QPS Simulation duprocessus global



QP

Le système n’est pas encore utilisé Tous les éléments sont prêts et disponibles en environnement de

production Partie statique / vérification des éléments organisationnels du

système (formations, qualifications précédentes, documentation (utilisateur et ingénierie))

QP-A ou QP-1(Avant mise

en exploitation)

Le système est utilisé Partie dynamique / suivi de l’évolution du système dans le temps

(monitoring)

QP-I ou QP-R(suivi Régulier)



Exemple : Sécurité d’accès

Test de la fonction gestion des droits d’accèsQO

Vérification de l’attribution des droits / responsabilités Vérification de l’adéquation entre les droits d’accès, les exigences

et les procéduresQPA

Vérification hebdomadaire que uniquement la personne qualifiée a libéré les lots

Vérification hebdomadaire que toutes nouvelles demandes d’accès ont été acceptées uniquement après une demande officielle et une formation

QPI



Ordonnancement de la QP

ENVIRONNEMENTDE

VALIDATION

ENVIRONNEMENTDE

PRODUCTION

« Démarrage »

QPA QPS

Avant mise en exploitation

QPI

Après mise en exploitation

QO QIQI

QPI impérativement réalisée dans desconditions réelles avec les procéduresapprouvées et les opérateurs formés

Libération formelle du système pour mise en exploitation



+ Le processus de transfert doit être contrôlé, documenté et communiqué Plan de transfert pour documenter les tâches, les responsabilités, les horaires et les

critères d'acceptation. Selon la criticité et la complexité d'un système document détaillé ou une liste de

contrôle approuvé par les parties transférantes et réceptrices

+ Après complétude des activités énumérées dans le plan de transfert, édition d’un rapport

Passage en Opération



+ Garantir que Il sera possible de faire un retour en arrière Les éléments de configuration relatifs aux logiciels et au matériel sont transférés à

l'organisation réglementée et aux organisations de support Toute la documentation est complète Les organisations opérationnelles et de support sont en place et les rôles sont définis La gestion du système, l'utilisation, l'administration et les processus opérationnels sont

établis Les services de support sont définis Les utilisateurs du système, les administrateurs et les organisations de support sont

formés. La migration des données est terminée La configuration de la sécurité est réalisée Les risques résiduels et les problèmes sont transférés aux organisations d'utilisateurs et

de soutien

Objectif du plan de transfert

Le transfert peut inclure le transfert du système et des processus support associés d’un QMS à un autre



+ Responsabilité pour le contrôle des changements

+ Responsabilité de la gestion de la configuration

+ Responsabilité de la gestion de la documentation

+ Responsabilité de l'administration du système

+ Acceptation des risques résiduels et responsabilité de la gestion des stratégies d'atténuation ou des mesures correctives

126

Transfert des responsabilités



Qualification de Performance (QP) : Points clés abordés

QP souvent Mal comprise Mal faite

Rapport de QPA = Autorisation de démarrage ?

QPS : possible mais pas obligatoire

QPI = confirmation des hypothèses de validation

Recevabilité de la QPI (validité des statistiques)

Ne pas oublier la libération formelle du système



Module 3Maintenance et exploitation



Après la validation initiale : Le plus dur commence ….

…. Maintenir le système validé !

Maintenance Phase



Un système va évoluer …



Gestion des modifications



Documents d’exploitation

Les documents nécessaires à l’utilisation quotidienne (utilisation) ,à la maintenance et aux incidents .(cahier de route)

Mais aussi :

Les documents nécessaires à l’administration : “SOPs should describe all necessary functions including control and management of any unique

features of the particular system, as well as controls necessary for regulatory compliance. The established Standard Operating Procedures (SOPs) for system administration should be

challenged during testing. “ Extrait GAMP

Les documents lés à la continuité d’activité: Business Continuity Plan (BCP): a document prepared to summarize the organization’s business

continuity activities. BCPs can address single or multiple systems. Procedures should be established to cover routine back-up of records, data, and software to a safe

storage location, adequately separated from the primary storage location, and at a frequency based on risk. There should be established procedures for recovery following a breakdown to ensure documented restoration and maintenance of GxP records and data.



La Revue Périodique des systèmes



Validation périodique versus Evaluation périodique !

+ Périodiquement, état des lieux du système

Analyser / Revoir TOUTES les modifications

Vérifier• les accès• les formations• la documentation• les hors spécifications• les modifications

Rédiger un rapport

Refaire une partie de la QO



Organiser le retrait

+ Lancer un Change Control

+ Pour définir le plan de retrait : Le plan de retrait doit être défini avant

la réalisation du remplacement ou du retrait du système

Prévoir le mode de traçabilité



Les activités à prévoir pour la partie système et données

+ Démontrer le statut qualifié jusqu’à la dernière utilisation (Data integrity)

+ * si remplacement, la migration des données doit être traitée dans l’exercice de validation du nouveau système.

+ Maitriser les risques liés aux données traitées par l’équipement



Module 4La documentation



Procédures pour la validation

D’autres procédures sont nécessaires, oupeuvent être impactées par la validation :

Procédures Qualité : Gestion de ladocumentation, Formation, …

Procédures d’utilisation du système

Procédures d’exploitation et demaintenance : Etalonnage,Maintenance, Installation,Archivage, Sauvegardes etrestauration, sécurité informatique(droits d’accès, plan de secours etde continuité …), …

Procédures de projet : Cycle de vieprojet ...

Procédure

validation

Procédure

Maîtrise des

modifications

ProcédureRe-

Validation /Evaluationpériodique

Procédure

Auditfournisseur



Guides et modèles pour la validation•Plan de validationModèles Guides

Plan de validation

Protocole et fiches(QF, QC, QI, QO, QP)

Analyses de risquesConduite

de qualification

Rapport de qualification(QF, QC, QI, QO, QP)

Rapport de validation

D’autres guides et modèles sontnécessaires, en particulier pour ledéveloppement des systèmes :rédaction des documents ingénierie(SBU, SF …), la programmationetc...

Procédure

validation

Procédure

Maîtrise des

modifications

ProcédureRe-

Validation /Evaluationpériodique

Procédure

Auditfournisseur



Revue de Conception

Qualification d’Installation

Qualification Opérationnelle

Qualification de Performance

Analyses de Risques

Revue de Code

ProtocolesQI

ProtocolesQO

ProtocolesQP

Revue de spécifications

FichesQI

FichesQO

FichesQP

Liens Matrice de traçabilité

DonnéesBrutes QI

DonnéesBrutes QO

Rapport de RC

Rapport de QI

Rapport de QO

Rapport de QP

Plan de validation

Dossier de validation

Rapport de Validation

ProtocolesQP

FichesQP

DonnéesBrutes QP

Ecarts

Ecarts

Ecarts

Ecarts



Rapport Final de Validation (1)

+ Conclusion Mise en service ?

+ Rappels Objectifs Domaine d’application Référence

+ Méthode Identifier et justifier les écarts avec le plan de validation

+ Responsabilité Identifier et justifier les écarts avec le plan de validation



Préparer

La documentation doit être rédigée en même temps que le projet avanceLa documentation doit être rédigée en même temps que le projet avance



Synthèse : VALIDER, c’est …

Vérifier : Revues (RC) et Audits

Procédures- Utilisation du

système- Support (modif…)

- Formation- Sécurité

DocumentationSystème

- SBU- Spécifications- Conceptions- Programmes

- Tests

Organisation- Politique Qualité

-Audits fournisseurs- Audits internes- Cycle de Vie- Standards

Qualifier : Tests (QI, QO, QP) + QF

• Fournisseur (QF)• Système- Installation (QI)- Opération (QO)- Performance (QP)

Maintenir :

le système dans un état validé



Vérification des connaissances : QCM



Vérification des connaissances

QCM



Et nous, est-ce que nous avons été bons ?

Evaluation de la formation



Et on vous libère enfin… FIN

Merci pour votre attention !

Validation des Systèmes d’Information ADAM Valérie Dates ...

Documents

Transcript of Validation des Systèmes d’Information ADAM Valérie Dates ...