Introduction aux

1
Introduction aux GAMP 4
2
Qui suis-je?

• Julie-Léa Lipszyc
• Directeur de projet / Spécialiste
  conformitéResponsable qualité
• SNC-Lavalin Pharma
• 8 000, boul. Décarie, 3e étage
• Montréal (Québec) H4P 2S4
• Tél. [phone], poste 2601
• Tél. cell. [phone]
• Courrieljulie.lipszyc_at_snclavalin.com

3
Les applications de ce cours

• Ce cours traite du développement, de
  limplémentation et de la validation associés aux
  systèmes informatisés, ce qui inclut les systèmes
  de contrôle de procédé, les systèmes informatisés
  utilisés dans la fabrication et les systèmes
  informatisés de gestion comme les PLC, DCS, MES,
  ERP, LIMS, etc.
• Il sapplique aussi à toute ressource impliquée
  dans la gestion, le développement,
  limplémentation ou la validation des systèmes
  informatisés. Practice 4 guide (GAMP 4)
• Il couvre le nouveau guide des Good Automated
  Manufacturing Practices 4 (GAMP 4).

4
Introduction

• Qui êtes-vous?
• Quel est votre domaine dactivité?
• Quelle connaissance avez-vous de ce sujet?
• Quelles sont vos attentes face à ce cours?

5
Plan du cours

• Cours magistral
• Exercice
• Quiz

6
Contenu du cours

• Vendredi de 830 à 1130
• Introduction à la réglementation
• Cycle de vie du développement et de la validation
• Planification de la validation
• Catégorisation du logiciel et du matériel
• Audit des fournisseurs
• Gestion du risque
• Revues de conception et matrices de traçabilité
• Test du logiciel et du matériel
• Gestion des opérations
• Mercredi de 830 à 1030
• Étude de cas
• Quiz

7
Introduction à la réglementation
8
Rappel historique

• Food and Drug Act
• 1er commissaire de la FDA, Harvey Washington Wiley

9
Rappel historique

• Food, Drug and Cosmetic Act (1938)
• Réglementation des BPF (1979)
• 21 CFR Part 210, 211
• Guide to Inspection of Computerized Systems in
  Drug Processing (1983)
• 21 CFR Part 11 (1997)

10
Food, Drug and Cosmetic Act

• SEC. 501. 351 A drug or device shall be
  deemed to be adulterated
• (B) if it is a drug and the methods used in, or
  the facilities or controls used for, its
  manufacture, processing, packing, or holding do
  not conform to or are not operated or
  administered in conformity with current good
  manufacturing practice to assure that such drug
  meets the requirements of this chapter as to
  safety and has the identity and strength, and
  meets the quality and purity characteristics,
  which it purports or is represented to possess

11
Food Drug and Cosmetic Act

• SEC. 301. 331 The following acts and the
  causing thereof are hereby prohibited
• (a) The introduction or delivery for introduction
  into interstate commerce of any food, drug,
  device, or cosmetic that is adulterated or
  misbranded.
• (e) The refusal to permit access to or copying
  of any record or the failure to establish or
  maintain any record, or make any report, . or
  the refusal to permit access to or verification
  or copying of any such required record.
• (g) The manufacture within any Territory of any
  food, drug, device, or cosmetic that is
  adulterated or misbranded.

12
Food Drug and Cosmetic Act

• SEC. 303. 333
• (a)
• (1) Any person who violates a provision of
  section 301 shall be imprisoned for not more than
  one year or fined not more than 1,000, or both.
• (2) Notwithstanding the provisions of paragraph
  (1) of this section, if any person commits such a
  violation after a conviction him under this
  section has become final, or commits such a
  violation with the intent to defraud or mislead,
  such person shall be imprisoned for not more than
  three years or fined not more than 10,000 or
  both.

13
Exigences de la FDA

• Les systèmes doivent être validés pour prouver
  quils fonctionnent comme spécifié
• Les systèmes doivent être étalonnés
• Les systèmes doivent être contrôlés dans leur
  utilisation
• Les systèmes doivent assurer lintégrité et la
  sécurité des données

14
Quelques sections liées aux BPFa

• Applicables au matériel
• 211.63 Conception, dimensions et position des
  équipements
• 211.67 Nettoyage et entretien des équipements
• 211.68 Équipements automatiques, électroniques et
  mécaniques (calibrage)

15
Quelques sections liées aux BPFa

• Applicables aux logiciels
• 211.68 Équipements automatiques, électroniques et
  mécaniques (sécurité, fonctions, copies de
  sauvegarde, contrôle)
• 211.101 Chargement des matières premières
  (contre-vérification du chargement des
  ingrédients)
• 211.180 Exigences générales (média
  denregistrement, rétention, revue et accès)
• 211.188 Production par lots et dossiers de
  contrôle
• 211.192 Examen des dossiers de production
• Food, Drug and Cosmetic Act section 704(a)
  (permet un accès aux programmes pour inspection)
• Part 11 couvre ER-ES

16
Livre bleu de la FDA

• Guide to Inspection of Computerized Systems in
  Drug Processing (1983)
• Guide de référence pour les inspecteurs de la FDA
• Couvre le matériel et le logiciel
• Exige la validation des systèmes
• Fournit des lignes directrices pour la conception
  et la mise en œuvre des systèmes informatisés

17
Guides des politiques de conformité de la FDA

• CPG 7132a.07 Vérification des entrées sorties
• CPG 7132a.08 Identification du personnel dans
  les rapports de production par lots et les
  dossiers de contrôle
• CPG 7132a.11 Application des BPFa au matériel et
  au logiciel
• CPG 7132a.12 Responsabilité des fournisseurs
• CPG 7132a.15 Code source pour les logiciels
  dapplication du contrôle des procédés

18
Autres rapports techniques de la FDA

• SW Development Activities, reference materials
  and training aids for investigators (1987)
• Normes et procédures de développement
• Exigences, spécifications et design
• Planification des tests et méthode dessais
• Installation, acceptation et qualification
• Contrôle des changements et évaluation des
  systèmes
• Procédures dassurance qualité

19
Doù viennent les GAMP?

• Groupe industriel appelé GAMP Forum, fondé en
  1990 et présidé par le Dr David Shelby
• Sous-groupe responsable de la rédaction des
  lignes directrices dirigé par le Dr Tony Margetts
• Première version en 1994
• Version 2 en 1996
• Version 3 en 1998
• Version 4 en 2001

20
Quoi de neuf dans les GAMP4?

• Les sections sur les fournisseurs et les clients
  sont fusionnées
• Matière nouvelle ou révisée sur
• Validation
• Audits des fournisseurs
• Catégories des logiciels et du matériel
• Sécurité des systèmes automatisés
• Plan de contingence
• Cycle de vie et stratégie de validation
• Évaluation des risques
• Essais des systèmes automatisés
• Revue de conception et matrices de traçabilité
• Copie de sauvegarde et récupération des logiciels
  et des données

21
Objet des GAMP 4

• Aider les compagnies pharmaceutiques à obtenir
  des systèmes automatisés validés et conformes
• Orienter les fournisseurs de systèmes automatisés
• Dans le développement et lentretien des systèmes
• Dans la préparation de la documentation
• CECI NEST PAS UNE EXIGENCE DE LA FDA!

22
Portée des GAMP 4

• Les GAMP 4 sont prévues pour être utilisées tant
  par les utilisateurs que par les fournisseurs de
  systèmes automatisés qui ont un impact sur la
  qualité de la production, la sécurité, lidentité
  ou lefficacité, comme
• Systèmes de laboratoire et de production
  automatisés
• Contrôle des procédés
• Systèmes informatiques comme MES, LIMS, MRP, ERP,
  etc.
• Elles incluent le logiciel, le matériel et les
  réseaux

23
Avantages des GAMP 4

• Harmoniser la terminologie utilisée dans le
  développement
• Réduire les temps et coûts de développement et de
  validation
• Améliorer la conformité et réduire les risques
• Fournir un cadre de travail (framework) pour la
  convergence avec les normes existantes
• Clarifier les rôles et responsabilités entre les
  usagers et les fournisseurs

24
Cycle de vie du développement et de la validation
25
Cycle de vie des systèmes autonomes activités et
documentation
26
Partie A
27
Documents de développement

• Spécifications des besoins des utilisateurs (URS)
• Elles décrivent ce que le système est supposé
  faire
• Elle font partie intégrante du contrat en
  fournissant les exigences clef du système
• Une version préliminaire est envoyée au
  fournisseur dans le cadre du processus de
  sélection du fournisseur
• Elles doivent inclure toutes les exigences
  essentielles et les exigences souhaitables
• Une version finale révisée doit être émise quand
  le fournisseur a été choisi.
• Elles doivent être maintenues durant tout le
  cycle de vie de développement
• Elles sont liées aux qualifications de rendement
  (PQ)
• Chaque énoncé dune exigence doit être référencé
  une seule fois
• Toutes les exigences doivent être testables
• Elles sont généralement rédigées par lusager

28
Documents de développement

• Spécifications fonctionnelles (FS)
• Elles décrivent comment le système va faire pour
  remplir les exigences
• Elles peuvent inclure des schémas, des modèles
  dinterfaces graphiques, etc.
• Une version préliminaire peut être envoyée au
  fournisseur et/ou client comme partie intégrante
  de la proposition
• Elles doivent être mises à jour durant tout le
  cycle de vie de développement
• Toutes les fonctions doivent être testables
• Elles devraient être traçables jusquà lURS
• Elles sont liées aux qualifications dopération
  (OQ)
• Elles sont généralement rédigées par le client et
  par le fournisseur

29
Documents de développement

• Spécifications de conception (DS)
• Elles décrivent comment le système sera construit
• Elles peuvent inclure des dessins, des
  spécifications, des détails dinterface
  graphique, etc.
• Elles doivent être mises à jour durant tout le
  cycle de vie de développement
• Elles doivent être liées aux Qualification de
  lInstallation (QI)
• Elles sont généralement rédigées par le
  fournisseur

30
Quest-ce que la validation?

• Selon la définition de la FDA, la validation
  cest
• Establishing documented evidence which provide a
  high degree of assurance that a specific process
  will consistently produce a product meeting its
  pre-determined specifications and quality
  attributes

31
Partie B
32
Documents de validation

• Plan Maître de Validation
• Document qui décrit la stratégie générale et les
  parties responsables de la validation dun
  système dans son environnement dexploitation
• Qualification de lInstallation (IQ)
• Vérification documentée quun système est
  installé conformément aux spécifications écrites
  et pré approuvées
• Qualification Opérationelle (OQ)
• Vérification documentée quun système fonctionne
  conformément aux spécifications écrites et pré
  approuvées sur sa plage de fonctionnement

33
Documents de validation

• Qualification de la Performance (PQ)
• Vérification documentée quun système est capable
  de fonctionner ou contrôler conformément aux
  spécifications écrites et pré approuvées
  lorsquil fonctionne dans sa plage de
  fonctionnement spécifiée
• Qualification du Design (DQ)
• Vérification documentée qui prouve que le design
  de lusine, des systèmes et de léquipement
  rencontre les spécifications établies. Ceci
  implique des revues planifiées et systématiques
  des spécifications, de la conception et du
  développement durant tout le cycle de vie

34
Documents de validation

• Test dacceptation
• Essai mené pour déterminer si un système
  satisfait ou non aux critères dacceptation et
  permet au client de déterminer sil doit accepter
  ou non le système.
• Essais dacceptation à lusine (FAT)
• Essai dacceptation mené dans lusine du
  fournisseur qui implique généralement le
  fournisseur.
• Essais dacceptation sur le site (SAT)
• Essai mené chez le client qui implique
  généralement le client.

35
Contrôle des changements au projet

• Nécessaire pour assurer le suivi du projet.
• Outils utilisables
• Outils de gestion de la configuration
• Outils CASE
• Outils de modélisation.
• Les changements apportés durant le prototypage
  peuvent être exclus.
• Une demande de changement devrait être utilisée
  et approuvée avant de mettre le changement en
  œuvre.
• Les renseignements suivants devraient être
  identifiés
• Lentendue des travaux et quels éléments
  contrôlés sont affectés
• Limpact du changement proposé et lévaluation
  des risques
• Révision de la documentation
• Les tests et les vérifications nécessaires
• Tout plan de contingence en cas de problèmes avec
  les changements lors de la mise en service.

36
Activités de validation versus activités de
développement
37
Relation entre les spécifications et la
qualification
Source GAMP 4
38
Contenu dun URS

• Introduction
• Survol du système
• Exigences opérationnelles
• Fonctions mode de fonctionnement, algorithme,
  performance et synchronisation, défaillances,
  sécurité
• Données traitement des données, définition des
  données, capacité, vitesse daccès, archive
• Interfaces interface usager avec les rôles ou
  fonctions, les autres systèmes, les équipements
  et linstrumentation
• Environnement Espace, conditions physiques, etc.

39
Contenu dun URS

• Contraintes
• Échelles de temps et jalons
• Compatibilité système dexploitation,
  compatibilité avec systèmes existants, bloc de
  temps, jalons, etc.
• Disponibilité périodes maximales allouée à
  lentretien, temps dindisponibilité, etc.
• Contrainte procédurale questions légales,
  méthodes de travail, niveau de compétence, etc.
• Entretien facilité, agrandissement,
  échelonnabilité (scalability), durée de vie utile
  supposée
• Cycle de vie
• Développement normes minimales, procédures pour
  PM et QA
• Essais besoins spéciaux, données dessai,
  simulateurs, essais en charge, etc.
• Livraison identification, media, format,
  documentation, données, outils, formation,
  archivage, etc.
• Soutien, etc.
• Glossaire

40
Contenu dune spécification fonctionnelle (FS)

• Introduction
• Survol du système
• Fonctions
• Description de haut niveau ramenée aux fonctions
• Buts des fonctions ou du système
• Rendement réponse, précision, débit
• Sécurité et protection
• Traçabilité à lURS
• Données
• Définition
• Accès accès en lecture/écriture, capacité des
  données, temps de rétention, archivage
• Sécurité et intégrité des données, etc.

41
Contenu dune spécification fonctionnelle (FS)

• Interface
• Interface avec les usagers
• Interface avec léquipement
• Données transmises ou reçues
• Protocoles de communication
• Traitement derreur
• Sécurité, etc.
• Attributs non fonctionnels
• Disponibilité fiabilité, redondance,
  vérification des erreurs, fonctionnement en mode
  dattente (standby)
• Maintenabilité expansion, excédent de capacité
  dE/S, durée de vie, etc.
• Glossaire
• Appendice

42
Contenu dune spécification de conception du
matériel

• Introduction
• Survol du système
• Système informatique
• Serveurs/PC éléments matériels primaires
• Stockage disque dur, lecteur de disquettes,
  sauvegarde sur bande
• Périphériques imprimantes, modems, NIC
• Interconnexion spécifications des câbles et des
  connecteurs, réseau, blindage
• Configuration Interrupteurs DIP, adressage de
  cartes, etc.
• Entrées-sorties
• DI, DO, AI, AO, compteur d'impulsions
• Pour chacun, spécifier la précision, léventail,
  le type, lisolation, etc.
• Environnement
• Température, humidité, bruit, sécurité physique,
  RF/EMI,
• Alimentation électrique
• Filtrage, charge, mise à la terre, alimentation
  sans coupure (UPS), etc.
• Glossaire

43
Contenu dune spécification de conception des
logiciels (DS)

• Introduction
• Survol du système
• Description du système
• Description de chaque module logiciel
• Interface entre les modules et lextérieur
• Diagrammes du système
• Modélisation du système
• Données du système
• Définition des données, modèles de bases de
  données
• Fichiers, enregistrements, type de données, etc.
• Description des modules
• Fonctionnement du module pseudocode
• Interface avec les autres modules
• Traitement des erreurs, vérification des données
• Paramètres dentrée-sortie
• Pass by reference, valeur des données
• Définition des variables locales, etc.
• Glossaire

44
Conclusion

• Tenir à jour les spécifications des systèmes est
  une exigence des GxP
• Il est possible dutiliser les documents du
  fournisseur pour compléter les IQ et OQ
• Si ce nest pas documenté, ce nest jamais
  arrivé!
• Les documents de qualification doivent se référer
  aux spécifications originales
• Suivre le cycle de vie des GAMP aidera à
  améliorer la conformité

45
Planification de la validation
46
Se rappeler de ces points important

• Requis pour les systèmes contrôlés GxP
• Sapplique aux nouveaux systèmes et aux systèmes
  existants
• Doit être approuvé par la direction et
  lassurance qualité
• Sera probablement revu par les inspecteurs

47
Pourquoi un plan maître de validation?

• Pour donner un aperçu du processus de validation
  lié au système, à lendroit, à linstallation ou
  à lorganisation
• Pour donner un résumé clair et concis de
• La politique de validation de lentreprise
• Lorganisation des activités de validation
• Des installations, systèmes, équipement ou
  processus à valider
• La liste de documentation, la structure et les
  formats qui seront utilisés
• Processus de contrôle des changements à suivre
• La planification et léchéancier
• Pour communiquer les renseignements aux
  intéressés assurance de la qualité, direction,
  audits internes
• Pour obtenir le soutien de la direction

48
Structure de la planification de la validation
Source GAMP 4
49
Table des matières dun plan directeur de
validation

• Page titre
• Page dapprobation
• Introduction et étendue des travaux
• Structure organisationnelle
• Processus dévaluation de la criticité GxP
• Stratégie de validation
• Contrôle des changements
• PON et formation
• Gestion de la documentation
• Échéancier et ressources
• Glossaire

50
Page titre, historique et table des matières

• Titre du document
• Numéro du document
• Date dapprobation du document courant
• Numéro de révision
• Nombre de pages
• Nom du fichier
• Historique du document, nom du réviseur et dates

51
Page dapprobation

• Nom des rédacteurs, réviseurs et approbateurs
• Assurance de la qualité
• Technologies de linformation
• Génie
• Production
• Laboratoires
• Affaires réglementaires
• Direction
• Numéro de révision
• Signification des signatures
• Date dapprobation
• Garder le nombre dapprobateurs au minimum requis

52
Introduction et étendue des travaux

• Description de haut niveau
• But du document
• Toute référence aux plans et politiques générales
  de validation applicables ou aux plans et
  politiques de CSV
• Description du niveau de planification
• Description et identification des aires et des
  systèmes couverts par le plan (usine, édifice,
  service, processus, produit, système, équipement,
  etc.)
• Références aux autre documents applicables
• Période de lévaluation périodique du plan

53
Structure organisationnelle

• Organigramme du projet de validation
• Définition des rôles et responsabilités
• Identification des personnes par appellation
  demploi ou fonction
• Directeur de projet
• Assurance de la qualité
• Propriétaire du système

54
Processus dévaluation de la criticité GxP

• Exigences p/r aux audits de fournisseurs
• Processus dévaluation des risques
• Exigence de détermination des niveaux de
  criticité GxP
• Procédure à suivre pour lévaluation
• Statut courant du processus
• Utilisation dune matrice de risque peut aider

55
Stratégie de validation

• Devrait donner un aperçu de la stratégie de
  validation à appliquer
• Quelles procédures de validation seront suivies?
• Quel cycle de vie à appliquer?
• Quelles sont les activités du projet?
• Sagit-il dune approche à plusieurs phases?
• Quelles sont les catégories matérielles et
  logicielles?
• Quels sont les critères dacceptation de chaque
  étape?
• Y aura-t-il des FAT ou des SAT?
• Quels seront les livrables de la validation?
• À quel intervalle doivent avoir lieu les
  évaluations périodiques pour garder le système
  dans un état validé?

56
Contrôle des changements

• Quelle stratégie de contrôle des changements
  sappliquera avant que le système ne soit
  installé (durant son développement)?
• Quelle stratégie de contrôle des changements
  sappliquera après que le système soit installé
  (durant son exploitation)?
• Qui peut autoriser les changements?
• Quest-ce qui sera affecté par les changements?
• Quelles sont les impacts des changements au
  niveau des BPFa?

57
PON et formation

• Quels PON sappliquent au système?
• Exploitation
• Entretien
• Sécurité
• Copie de sauvegarde et restauration des données
  et du système
• À quel sorte de formation le personnel doit
  assister?
• Quels groupes dusagers devraient suivre ces
  cours?
• Opérateurs
• Techniciens
• Ingénieurs
• Personnel de laboratoire
• Direction, etc.

58
Gestion des documents

• Quelles stratégie sera appliquée à la gestion des
  documents du projet?
• Y a-t-il un système de gestion de documents en
  place?
• Qui est responsable de tenir les documents à
  jour?
• Y a-t-il un programme de gestion de la
  configuration en place?
• Quels sont les modèles de documents à utiliser
  durant le projet?
• Quel est le plan de numérotation des documents?

59
Échéancier et ressources

• Un échéancier détaillée ou un diagramme de Gantt
  devrait être préparé au début et tenu à jour par
  la suite par le directeur de projet de validation
• Les besoins de ressources matérielles et humaines
  devraient être déterminés tôt durant le projet
• La durée des activités devrait aller de 2 jours à
  2 semaines
• Des jalons devraient être établis
• Lintervalle entre les réunions de statut de
  projet devrait être déterminé

60
Glossaire

• Cette section devrait contenir les définitions de
  tous les termes qui pourraient être étrangers aux
  lecteurs du document.

61
Préserver létat de validation

• Implique
• Formation
• PON
• Gestion du système
• Copie de sauvegarde et restauration
• Gestion de la configuration
• Contrôle des changements opérationnels
• Gestion de la sécurité
• Plan de contingence
• Évaluation périodique
• Etc.

62
Formation

• Planifiée
• Adaptée aux divers groupes dutilisateurs et au
  personnel de soutien
• Documentée
• Devrait couvrir
• Exploitation
• Entretien
• Sécurité
• Changements
• Copie de sauvegarde et restauration
• Etc.

63
Catégorisation des logiciels et du matériel
64
Catégorisation

• Pour évaluer les risques associés à un système
• Basé sur le risque dune défaillance du système
• Sur une échelle de 1 à 5 pour les logiciels
• Sur une échelle de 1 à 2 pour le matériel
• Fait généralement partie de la phase dévaluation
  des risques

65
Catégorie de logiciel 1

• Systèmes dexploitation
• Système dexploitation établi et disponible
  commercialement
• Pas sujet à la validation
• Le nom et la version devrait être documenté et
  vérifié durant la IQ
• Le contrôle des changements devrait être appliqué
  pour gérer les mises à jour
• Limpact des mise à jour devrait être déterminé
  par des essais
• Exemples Unix, Windows XP, VMS

66
Catégorie de logiciel 2

• Micrologiciel (firmware)
• Peut nécessiter de la configuration
• Les paramètres du micrologiciel devraient être
  vérifiés durant la IQ
• Les fonctionnalités devraient être testées durant
  la OQ
• Le contrôle des changements devrait être appliqué
  au micrologiciel ou aux paramètres de
  configuration
• Nécessite une PON et de la formation
• Des audits du fournisseur sont recommandés pour
  les systèmes hautement critiques ou complexes
• Les micrologiciels personnalisés devraient être
  considérés comme faisant partie de la catégorie 5
• Exemples balance, lecteur code à barres,
  contrôleur de périphériques microprogrammé,
  instrumentation SMART

67
Catégorie de logiciel 3

• Progiciels standards
• Standard, disponible commercialement ou progiciel
  grand public
• La configuration doit être limitée à
  létablissement de lenvironnement dexécution du
  progiciel
• Le nom du progiciel et la version devrait être
  documentée durant la IQ
• LURS et la spécification fonctionnelle devraient
  être documentés, revus et testés durant la OQ

68
Catégorie de logiciel 3 (suite)

• Progiciel standard
• La documentation du fournisseur (manuels
  dinstallation et dutilisation) devrait être
  évaluée et utilisée
• Des audits du fournisseur sont recommandés pour
  les systèmes hautement critiques ou complexes
• Le contrôle des changements devrait être appliqué
  pour gérer les changements à la configuration et
  les mises à jour
• Nécessite une PON et de la formation
• Exemples progiciels danalyse statistique,
  logiciel de CLHP

69
Catégorie de logiciel 4

• Progiciels configurables
• Fournit des interfaces standard et des fonctions
  qui peuvent être configurées selon les besoins
  spécifiques de lutilisateur ou les processus de
  fabrication
• Le progiciel devrait être reconnu et mature,
  sinon, il faudra le considérer comme faisant
  partie de la catégorie 5
• Un audit du fournisseur est généralement requis.
  Sil na pas de système qualité, alors il faudra
  considérer le progiciel comme faisant partie de
  la catégorie 5
• Une validation complète couvrant tout le cycle de
  vie du progiciel devrait être considéré
• Se concentrer sur les fonctions configurables
• Documentation du fournisseur (manuels
  dinstallation et dutilisation) devrait être
  évaluée et utilisée
• Le contrôle des changements devrait être utilisé
  pour gérer les changements à lapplication
• Chaque application est unique et spécifique à
  lusager
• Nécessite une SOP et de la formation
• Exemples SCADA, DCS, MES, LIMS, ERP, etc.

70
Catégorie de logiciel 5

• Logiciel personnalisé
• Développé sur mesure pour les affaires de
  lusager ou pour les besoins du processus de
  fabrication
• Peut inclure des progiciels dautres catégories
• Un audit du fournisseur est fortement recommandé
• Une validation complète couvrant lensemble du
  cycle de vie devrait être considérée
• Le fournisseur devrait fournir de la
  documentation (manuels dinstallation et
  dutilisation) qui sera alors évaluée et utilisée

71
Catégorie de logiciel 5

• Logiciel personnalisé
• Le contrôle des changements devrait être appliqué
  pour gérer les changements à lapplication
• Chaque application est unique et spécifique à
  lusager
• Nécessite une PON et de la formation
• Exemples Systèmes de pré-pesage personnalisés,
  applications développées en C, C, VB,
  interfacées avec dB comme Oracle, SQL Server, etc.

72
Tableurs

• Considérés de catégorie 3 sils sont utilisés
  pour créer des documents papier
• Considérés de catégorie 4 sils sont utilisés
  dans des tâches plus complexes ou qui impliquent,
  par exemple, des modèles
• Considérés de catégorie 5 sils sont utilisés
  avec des macros ou de la programmation
  personnalisée ou logique
• Nécessite une vérification et des essais
• Difficile détablir un contrôle des changements.
  Pour cette raison, ils devraient avoir une
  protection de feuille de travail
• Doivent être conformes aux règlements applicables
  comme les BPFa et le 21 CFR part 11

73
Développement dapplications et outils de
diagnostic

• Si loutil est utilisé pour supporter le
  processus de développement et de gestion, alors
  il nest pas considéré comme une application GxP.
• Si loutil est utilisé pour supporter le procédé
  administratif lui-même, alors il est considéré
  comme une application GxP. Les catégories GAMP
  sappliquent.
• Le contrôle des changements doit être appliqué
  pour la mise à jour des versions et lapplication
  doit être testée et vérifiée à nouveau.

74
Catégorie de matériel 1

• Composants matériels standard
• Devraient être documentés fabricant, modèle,
  numéro de version, numéro de série, etc.
• Acceptation matérielle et IQ
• Un produit pré-assemblé qui est sous scellé na
  pas besoin dêtre démonté puisque cela peut
  annuler la garantie
• La gestion de la configuration et le contrôle des
  changements sappliquent

75
Catégorie de matériel 2

• Composants matériels personnalisés
• Même que la catégorie 1 plus
• Devraient avoir une spécification de conception
  et être sujets à essais dacceptation
• Un audit du fournisseur devrait être mené
• Les systèmes assemblés utilisant des composantes
  de diverses sources nécessitent une vérification
  de compatibilité
• La configuration du matériel définie dans la
  documentation de conception et vérifiée durant la
  IQ

76
Audits des fournisseurs
77
Matière couverte par cette section

• Les raisons pour exécuter des audits de
  fournisseurs
• Les différents types daudits
• Le programme daudit
• Le processus daudit
• Audit joint
• Audit partagé
• Audit postal

78
Sapplique à

• Fournisseurs extérieurs de systèmes automatisés
• Groupe de développement et de support interne
• Fournisseurs éventuels de systèmes automatisés
• Fournisseurs actuels non audités

79
Les raisons pour exécuter des audits de
fournisseurs

• Afin de sassurer que la qualité fait partie
  intégrante du produit
• Pour sassurer que le système satisfera aux
  exigences techniques, commerciales et
  réglementaires
• Pour avoir des preuves écrites que le fournisseur
  développe son système en utilisant une méthode
  adéquate et que des essais documentés sont menés
  à divers stades du développement du produit
• Pour clarifier les attentes et les exigences de
  lusager
• Pour identifier et réduire les risques
• Cest une partie importante du processus
  dévaluation et de sélection du fournisseur

80
Types daudits

• Audit interne
• Audit du fournisseur par lusager ou son
  représentant
• Audit du fournisseur par une organisation
  indépendante de lusager

81
Buts de laudit

• Recueillir des renseignements sur lentreprise et
  sur son système qualité (QMS)
• Évaluer la capacité de lentreprise à livrer le
  système
• Vérifier les preuves de la conformité de
  lentreprise à leur QMS
• Évaluer la situation financière de lentreprise
• Évaluer le rendement et la qualité du produit

82
Les étapes de laudit

• Évaluation préliminaire
• Évaluation initiale
• Généralement faite par questionnaire
• Audit détaillé
• Exécuté durant la planification de la validation
• Visite chez le fournisseur
• Avant le bon de commande
• Audit de suivi
• Contrôle des problèmes soulevés lors de laudit
  détaillé
• Contrôle des actions correctives
• Montre la bonne volonté du fournisseur
• Audits périodiques
• Vérifier que le fournisseur respecte les normes
  requises
• Lintervalle peut varier

83
Calendrier daudit

• Un calendrier daudit peut savérer être une
  bonne pratique, particulièrement sil sagit
  dauditer plusieurs fournisseurs
• Peuvent réduire les coûts de vérification
• Audits joints dun même fournisseur
• Plusieurs fournisseurs dans une même ville

84
Le processus daudit

• Faire une évaluation préliminaire
• Planifier et exécuter un audit détaillé
• Produire un rapport daudit
• Déterminer les actions correctives et faire le
  suivi (audit)
• Accepter ou rejeter le fournisseur

85
Évaluation préliminaire

• Aperçu de lentreprise, taille, structure,
  performance du support, plan de développement,
  etc.
• Gestion organisationnelle et gestion de la
  qualité
• Statut du système dassurance de la qualité
• Formation et expérience de personnel
• Recours à un sous-contractant
• Planification et gestion du produit ou du projet
• Cycle de vie du développement logiciel

86
Évaluation préliminaire

• Outils et méthodologie de projet (CASE, gestion
  de la configuration, système de gestion de
  documents, etc.)
• Revue de contenu et de format des URS, FS, DS et
  protocoles dessais
• Normes de codage
• Stratégies et compte-rendu dessais
• Soutien, entretien, conventions de services
• Sécurité
• Plan de contingence
• Bien dautres choses encore

87
Planification daudit

• Déterminer létendue de laudit
• Se concentrer sur
• Audit Détaillé tous les aspects
• Audit de suivi secteur spécifique de
  préoccupation
• Audit périodique lacunes trouvées durant les
  audits précédents
• Un programme daudit sera alors préparé
• Choisir une équipe daudit
• Systèmes simples un auditeur
• Système complexe deux personnes ou plus
• Assigner un responsable daudit expérimenté
• Avertir le fournisseur
• De toute implication dune tierce partie
• Des détails de laudit (buts, étendue,
  localisation, choix du moment et le détail de
  léquipe daudit)
• Du programme préliminaire
• Du personnel du fournisseur requis
• De lentente de confidentialité AVANT laudit

88
Exécution de laudit

• Séance douverture
• Introduction
• But et étendue de la réunion
• Le programme peut être modifié ou réorganisé en
  fonction de la situation réelle
• Problèmes de logistique
• Examen et inspection
• Partie principale
• Examiner les pratiques et les dossiers
• Identifier tous les secteurs de préoccupation et
  les porter à lattention du fournisseur
• Adopter une approche  montrez-moi comment
• Utiliser une liste de contrôle mais rester
  attentif aux imprévus

89
Exécution de laudit

• Séance de clôture
• Dresser une liste des observations notées durant
  laudit, tant les points positifs que négatifs
• Donner loccasion au fournisseur de réagir aux
  observations
• Expliquer les prochaines étapes
• Pas de surprise

90
Rapport daudit

• Document important de QA
• Fournit un rapport formel de laudit et de ses
  observations
• Principal intrant à la détermination des actions
  correctives
• Documente objectivement le choix entre
  sélectionner un nouveau fournisseur ou continuer
  à sapprovisionner chez le même fournisseur
• Donne la date de réception du plan dactions
  correctives
• Peut inclure des recommandations spécifiques

91
Rapport daudit

• Contient normalement
• Introduction
• Étendue de laudit
• Programme daudit, critères et représentants
• Constatations détaillées
• Compte-rendu de la séance de clôture
• Conclusions
• Ne devrait pas être fournit aux inspecteurs en
  réglementation avec le dossier dassurance de la
  qualité

92
Acceptation ou rejet du fournisseur

• Basé sur les conclusions de laudit
• Plusieurs scénarios
• Sapprovisionner inconditionnellement chez ce
  fournisseur
• Sapprovisionner chez ce fournisseur pour
  certains produits ou versions seulement
• Sapprovisionner chez ce fournisseur à la
  condition dappliquer des actions correctives
• Sentendre sur lapplication dun QMS pour ce
  projet
• Interdire de sapprovisionner chez ce fournisseur

93
Actions correctives et vérification de suivi

• Pour les actions correctives
• Nécessitent des preuves documentées de
  lexécution réussie
• Nouvelles procédures
• Rapports dessais
• Documents de revue de design et de la
  programmation
• Une lettre de confirmation généralement nest pas
  suffisante
• Si nécessaire, un audit de suivi peut être
  planifié, exécuté et documenté
• Les conclusions de lexamen du rapport daudit
  devraient être faire lobjet dun compte-rendu
  formel et devraient être documentées par lusager

94
Audits de situation intérimaire

• La fréquence dépend de divers facteurs incluant
  les résultats des audits précédents
• Devraient être planifiés, exécutés et documentés
• Se concentre habituellement sur des points
  spécifiques

95
Audits joints

• Inconvénients des audits typiques
• Exigeant en terme de ressources pour le
  fournisseur et lusager
• Exige du temps et des efforts de la part du
  fournisseur
• Des normes daudit multiples peuvent dérouter les
  fournisseurs
• Avantage des audits joints
• Réduit le temps et les efforts consacrés aux
  audit par le fournisseur et lusager
• Augmente la coopération entre les entreprises
• Se fait selon des normes daudit communes
• Problèmes des adits joints
• Confidentialité et responsabilité
• Organisation et taille de léquipe daudit
• Formation commune et cohérente des auditeurs
• Les attentes des usager peuvent être différents

96
Rapports daudits partagés

• Certains usagers partagent leurs rapports daudit
  après avoir audité les fournisseurs
• Les points suivants devraient être documentés
• Létendue de laudit est valide pour le
  destinataire du rapport
• La compétence des auditeurs remplit les exigences
  du destinataire
• Le processus daudit est acceptable pour le
  destinataire
• Problèmes de confidentialité et de responsabilité

97
Audits postaux

• Coûts daudit réduits
• Accélère le processus
• Ne remplace pas une visite
• Exécuté généralement durant
• Le processus d'appel d'offres
• Laudit préliminaire
• Les vérifications de suivi
• Les audits de situation intérimaire
• Lévaluation dautres établissements (du même
  fournisseur) utilisant le même QMS
• La personne qui remplit laudit ne devrait pas
  être liée au développement du produit
• Utilise une liste de contrôle
• Complété par des preuves documentées

98
Gestion du risque
99
Évaluation du risque

• Pour déterminer le degré de validation requise
• Pour déterminer la criticité daffaire et
  dopération du système
• Pour déterminer les exigences et les options de
  lusager
• Pour soutenir le processus de sélection du
  fournisseur
• Identifier les zones à risque sur lesquelles
  concentrer les ressources limitées!

100
Le processus dévaluation du risque
Source GAMP 4
101
Identifier un risque GxP

• Cette étape détermine si la fonction du système
  représente un risque GxP ou non
• Exemples de risques
• Formulation inexacte
• Erreur de matières premières
• Erreur de matériel dassemblage
• Intégrité des résultats de contrôle de la qualité
  en laboratoire
• Statuts de lots inexacts
• Traçabilité des lots
• Etc.

102
Identifier les risques daffaires

• Cette étape détermine si la fonction système
  représente ou non un risque daffaires
• Exemples de risques
• Mauvaise presse
• Responsabilité des actionnaires
• Impact sur les revenus
• Avantage concurrentiel
• Préjudice potentiel
• Temps dinactivité ou dommages
• Etc.

103
Identifier les scénarios de risque
Fonction Sous-fonction Scénarios de risque Effet
Approvisionnement Ouverture dun bon de commande Entrée inexacte de la force du produit durant la saisie du bon Réception de matériel de mauvaise force Rejet de matériel à la livraison Rupture de stock
Utilisation dun fournisseur non approuvé Problème à maintenir le processus de fabrication Qualité du produit fini irrégulière Rejet du produit Rupture de stock
Source GAMP 4
104
Évaluer la probabilité du risque

• Fréquence ou probabilité quun événement
  indésirable se produise
• Mesuré sur une période donnée ou pour une
  quantité de transactions
• Basse lt1 par 10 000 transactions
• Moyenne lt1 par 1 000 transactions
• Haute lt1 par 100 transactions

105
Évaluer la criticité du risque

• Impact sur la conformité aux règlements
• Impact financier
• Réputation de la compagnie
• Peut être mesurée ainsi
• Basse incidence mineure, pas deffet nuisible à
  long terme
• Moyenne incidence moyenne, effets nuisibles à
  court et moyen termes
• Haute incidence majeure avec des effets à long
  terme et des effets catastrophiques à court terme

106
Classification des risques
Source GAMP 4
107
Évaluer la probabilité de détection

• Pour identifier si un risque peut être reconnu ou
  détecté par dautres moyens dans le systèmes
• La probabilité quun risque soit détecté peut
  être évaluée ainsi
• Basse détection de la défaillance peu probable
• Moyenne détection de la défaillance
  raisonnablement probable
• Haut détection de la défaillance hautement
  probable

108
Déterminer les mesures appropriées pour atténuer
les risques
Source GAMP 4
109
Revue de conception et matrices de traçabilité
110
Revue de conception

• Évaluer les livrables en fonction des normes et
  des exigences
• Identifier les problèmes et proposer les
  solutions nécessaires
• Est une revue planifiée et systématique des
  spécifications, de la conception et du
  développement
• Est une partie importante du processus de
  vérification
• Est aussi appelée qualification deu design (DQ)

111
Quand exécuter une revue de conception?

• Mené à chaque niveau de détail des spécifications
• URS
• Spécification fonctionnelle
• Spécification de design
• Dessins
• Devrait impliquer
• Lutilisateur final ou son représentant
• Concepteurs
• Assurance de la qualité
• Devrait suivre un plan de revue de conception

112
Matrices de traçabilité

• Mettent en relation deux produits du processus de
  développement ou plus
• Assureront que
• Toutes les exigences seront satisfaites et
  reliées aux éléments de la conception
• Toutes les exigences seront contrôlées et
  pourront être reliées à des tests ou à des
  contrôles démontrant que les exigences ont été
  satisfaites

113
Matrices de traçabilité

• Linformation est généralement consignée sous
  forme de tableaux
• Devrait être mise à jour au cours du cycle de vie
  de développement
• Devrait être conservée comme preuve que les
  exigences ont été implémentées et testées

114
Exemple dune matrice de traçabilité
Source GAMP 4
115
Test du logiciel et du matériel
116
Pourquoi tester?

• Pour fournir des preuves documentées que le
  système fonctionne comme spécifié (URS, FS, etc.)
• Pour déterminer le rendement et la fiabilité du
  système
• Garder un journal des essais est une exigence
  principale de la réglementation
• Parce quil ny a pas de logiciel exempt
  derreur, il est important deffectuer des essais
  au cours du processus de développement

117
Lignes directrices des tests

• Devraient être planifiés
• Devraient être exécutés en utilisant des
  procédures dessais prédéfinies, approuvées et
  sujettes au contrôle de version
• Devraient être exécutés par des personnes
  indépendantes, objectives, qualifiées et formées
• Devraient couvrir tous les domaines pertinents du
  système
• Devraient être documentés (date, signatures et
  titres des examinateurs, réviseurs, approbateurs)
• Devraient inclure des tests structurels et
  fonctionnels
• Les procédures dessais devraient inclure le but,
  la méthode et les résultat attendus des tests

118
Lignes directrices des tests

• Toute déviation à la procédure durant son
  exécution devra être notée et paraphée
  lisiblement
• Toute correction devra être barrée dune simple
  ligne, paraphée et datée
• Toute la documentation des essais devrait être
  conservée
• Tous les tests devraient indiquer, dans un énoncé
  final, si les critères dacceptation ont été
  atteints ou non
• Les essais devraient être exécutés avec des
  instruments étalonnés
• Toute déviation devrait être enregistrée et
  traçable à travers les corrections et réexamens
  jusquà la fin des tests
• Les résultats devraient être révisés pour
  sassurer quils soient complets et exacts

119
Plan de test

• Devrait déterminer le niveau et le type de tests
  pertinents pour un système
• Devrait déterminer la méthode dessais
• Devrait indiquer le moment choisi
• Devrait définir les rôles et responsabilités
• Devrait définir le processus dapprobation
• Devrait indiquer le matériel de test
• Devrait inclure une matrice de traçabilité

120
Types de tests

• Test structurel (boîte blanche)
• Vérifie la structure interne du code de chaque
  module
• Inclut un examen du code, analyse des
  branchements, audit de la procédure de
  programmation et du code mort
• Nécessite un accès au code
• Nécessite une expertise spécifique en
  programmation et en informatique
• Test fonctionnel (boîte noire)
• Ignore le fonctionnement interne du système
• Se concentre sur le résultat des sorties
  répondant à des modifications des entrées
• Vérifie généralement les conditions aux limites

121
Méthode de tests

• Tests des modules logiciels
• Tests du matériel
• Tests dintégration du logiciel
• Tests dintégration du système
• Tests dacceptation en usine et sur le site

122
Tests statiques du logiciel

• Revue générale et inspection du code du logiciel
• Vérification des normes de codage
• Vérification de la logique et des branchements
• Vérification des commentaires, des en-têtes de
  programme, des règles daffectation des noms
  variables, etc.
• Recherche du code mort

123
Tests modulaires

• Vérifie que chaque module logiciel respecte ses
  spécifications
• Vérifie les fonctionnalités du module avec la
  spécification de design
• On peut utiliser des outils pour vérifier les
  modules

124
Tests du matériel

• Vérifie que le matériel respecte ses
  spécifications
• Vérifie que le matériel fonctionne de la manière
  attendue
• Vérifie que le matériel est bien configuré et
  installé
• Ceci sapplique aussi aux réseaux
• Peut inclure une vérification des E/S, des
  alarmes, de la configuration, des essais de
  continuité, etc.

125
Tests dintégration du logiciel

• Vérifie que tous les modules logiciels
  fonctionnent de la manière attendue quand ils
  sont intégrés ensembles
• Nincluent pas, généralement, lintégration de
  tous les composants matériels
• Vérifie que tous les modules communiquent entre
  eux comme spécifié
• Compare les fonctionnalités du module avec la
  spécification fonctionnelle et la spécification
  de conception

126
Tests dintégration du système

• Semblables aux tests dintégration du logiciel
  mais incluent le matériel
• Certains composants matériels peuvent ne pas être
  disponibles à ce moment
• Incluent, généralement, les essais de limites, de
  paramètres critiques, etc.

127
Tests dacceptation

• Tests dacceptation en usine et sur le site
• Contiennent généralement des jalons contractuels
• Cherchent à prouver le bon fonctionnement du
  matériel, du logiciel et de linstrumentation
• Devraient être basés sur des protocoles approuvés
• Les catégorie de logiciel et de matériel
  influenceront le niveau et la profondeur des
  essais
• Les conclusions tirées des essais devraient être
  documentées dans le protocole et le rapport de
  FAT
• Peuvent être combiné à dautres activités de mise
  en service
• Ils valent le coût de leur exécution!

128
Scénarios de test

• Devraient inclure les point suivants
• Nom du test et références aux URS, FS et DS
• Buts des essais
• Étapes et méthode dessais
• Critères dacceptation et résultats attendus
• Résultats obtenus
• Conclusions des tests
• Signature des examinateurs, réviseurs et
  approbateurs et la date

129
Gestion des opérations
130
Gestion de lexploitation

• Il vous faut fournir aux autorités réglementaires
  la preuve documentée que vous avez le contrôle de
  votre système
• Exige, normalement
• Plans et procédures opérationnels
• Formation
• Gestion et résolution de problèmes
• Contrats de service
• Gestion des systèmes
• Copie de sauvegarde et restauration des données
  et des logiciels
• Gestion de la configuration
• Contrôle des changements opérationnels
• Administration de la sécurité
• Surveillance de la performance des systèmes
• Conservation et archivage des données
• Plan de contingence
• Réévaluation périodique
• Mise hors service du système

131
Plans et procédures opérationnels

• Des plans opérationnels doivent être en place
  pour sassurer que les activités de soutien sont
  mises au point, révisées, approuvées et, sil y a
  lieu, testées avant que le système ne devienne
  opérationnel
• Les PON doivent être développées et approuvées
  avant que le système ne devienne opérationnel
• Ces PON sont sujettes au contrôle des changements

132
Formation

• Plans de formation pour lutilisation et le
  soutien des systèmes
• Prendre en compte divers groupes dutilisateurs
• Opérateur
• Superviseur
• Personnel du soutien technique
• Direction
• Il faut traiter de limpact réglementaire de
  lutilisation de ce système
• Linformation sur la formation doit être
  conservée dans un dossier de formation

133
Gestion et résolution de problèmes

• Exposer comment les défaillan