Questions et réponses par vidéo, webinaire sur Part 11 / Annexe 11

Questions et réponses sur les réglementations 21 CFR Part 11 et Annexe 11
Sciences de la vie
Bienvenue à cette nouvelle session de questions et réponses par vidéo qui fait suite à notre dernier webinaire sur les réglementations 21 CFR Part 11 et Annexe 11, et comment elles s'appliquent aux systèmes de surveillance environnementale. Dans cette vidéo, Paul Daniel, notre expert senior en réglementation GxP, répond aux questions auxquelles nous n'avons pas pu répondre pendant le webinaire. Conformité du système de surveillance continu à la réglementation CFR (Partie 11) et à l'Annexe 11 : plus simple que vous le pensez 
Trouvez deux nouvelles notes d'application sur les réglementations 21 CFR Part 11 et Annexe 11 ci-dessous ainsi qu'un lien vers un webinaire sur la cybersécurité dans les systèmes GxP.
 
Si vous avez d'autres questions, postez-les dans la partie Commentaire située sous la transcription de la vidéo.
Question :
Pourquoi les contrôles d'exactitude ne sont-ils par obligatoires sur un système de surveillance ?
Réponse :
Dans le contexte de ce webinaire, l'obligation en matière de contrôles d'exactitude est définie de manière restrictive par l'Annexe 11 comme suit :

« Lorsque les données critiques sont introduites manuellement, il est nécessaire de prévoir un contrôle supplémentaire pour vérifier leur exactitude. Ce contrôle peut être effectué par un deuxième opérateur ou par des moyens électroniques validés. La criticité et les conséquences potentielles de données erronées ou incorrectement saisies doivent être couvertes par la gestion du risque. »

Dans un système de surveillance, je dirais qu'aucune donnée critique n'est saisie manuellement. Puisque les données critiques ne sont pas saisies manuellement, les contrôles d'exactitude tels qu'ils sont définis dans l'Annexe 11 ne s'appliquent pas.

Maintenant, si nous élargissons l'idée de « contrôles d'exactitude », il semble raisonnable de contrôler l'exactitude des données.  Et bien sûr, un système de surveillance comme viewLinc dispose de plusieurs méthodes pour contrôler automatiquement l'exactitude des données. Premièrement, les capteurs sont tous calibrés. Deuxièmement, lorsque des données sont transmises au système, l'exhaustivité des paquets de données est contrôlée pour garantir qu'ils n'ont pas changé et qu'ils n'ont pas été altérés au cours de la transmission. Troisièmement, si des données, comme des paramètres ou des seuils, sont saisies manuellement dans viewLinc, leur format est vérifié. Par exemple, une adresse e-mail doit contenir un signe @ et se terminer par un .com ou un .net ou tout autre suffixe valide. De plus, tous les seuils doivent être des données numériques. Il s'agit de deux exemples Toutefois, ces données ne sont pas forcément critiques même si elles sont saisies manuellement. C'est contraire à l'intuition, par rapport à l' Annexe 11, mais c'est ce que stipule la directive. Nous pourrions faire un webinaire complet sur les manques constatés dans les réglementations Part 11 et Annexe 11. 
 
Question :
L'audit trail doit être disponible, convertible dans un format globalement compréhensible et revu à fréquence régulière.  Savez-vous ce que l'on entend par « à fréquence régulière » ? Par exemple, tous les ans, avant le lancement par lots ?
Réponse :
L'audit trail doit être revu à une fréquence qui fait sens. En général, il ne s'agit pas d'une période de temps, mais d'un calendrier qui coïncide avec un examen ou un événement d'approbation impliquant les données en question. 

Par exemple, si j'approuve une étape de fabrication qui exige de maintenir une unité de fabrication entre 10 °C et 25 °C, il pourrait être intéressant de revoir l'audit trail et de vérifier que les données n'ont pas été modifiées par personne.  Si j'attends un an avant de passer en revue les données, ce lot de produits sera épuisé depuis longtemps et il ne restera plus qu'à tester les échantillons restants voire rappeler le lot. 

Peut-être qu'un système de gestion de l'information au laboratoire collectant les données d'un chromatographe serait un meilleur exemple. Les données du chromatographe doivent être ajustées et manipulées pour être compréhensibles et évaluées.  Si je suis en charge du contrôle de la qualité et que je viens de tester un échantillon avec un chromatographe, les enregistrements d'audit trail pertinents doivent être revus en même temps que le rapport du chromatographe afin que l'approbateur vérifie que les modifications correctes ont été apportées.
 
Ainsi, du fait des deux choix dans votre question, à savoir tous les ans (période de temps) ou au lancement par lots (événement défini), je choisirais l'événement défini. Malgré tout, ce qu'on entend par événement défini approprié va dépendre du système informatisé utilisé. Un système bien conçu doit intégrer un moyen permettant de garantir que les réviseurs et les approbateurs d'enregistrement accèdent facilement à l'audit trail pour l'événement défini en cours d'examen.
 
Question :
Le système viewLinc surveille-t-il les données quand le système est hors ligne et informe-t-il les utilisateurs quand le système repasse en ligne ?
Réponse :
Le système viewLinc est conçu pour être en ligne tout le temps. Le serveur viewLinc doit fonctionner 24 h/24 et 7 j/7, tout comme les services viewLinc doivent être exécutés sur le serveur en continu.
Si, pour une raison quelconque, le serveur viewLinc est hors ligne et repasse en ligne, voici ce qui se produit : 
 
  • Le journal des événements enregistre la récupération du système. 
  • Lors de l'événement suivant d'analyse du système, le système remplit toutes les données collectées par les enregistreurs de données qui n'ont pas été transmises à viewLinc lorsqu'il était hors ligne. 
 
Question :
Limitez-vous un processus de validation au système ou l'étendez-vous à l'ensemble de l'installation ? 
Réponse :
Oui, les deux. Je pense que la réglementation 21 CFR Part 11 stipule clairement la validation d' un système unique. Mais, avant de pouvoir réellement commencer à valider des systèmes uniques, nous devons disposer d'un plan directeur de validation qui définit quels systèmes doivent être validés. Ce plan doit comprendre la criticité ou la hiérarchisation des systèmes pour la validation. Des procédures de validation doivent également être instaurées pour définir la méthode d'exécution des validations au sein de l'installation. 
 
L'effet indirect de cette méthode est que nous ne pouvons pas vraiment valider un système unique sans avoir instauré une stratégie de validation au niveau de l'installation. Prenons l'image d'un mur que nous construisons rangée de briques par rangée de briques. La validation d'un système conformément à la réglementation 21 CFR Part 11 reviendrait à aligner des briques à la quatrième rangée, juste au-dessus des briques de procédure, de politique et de planification placées au-dessous. Part 11 se concentre uniquement sur le système, mais par implication, elle doit inclure l'ensemble de l'installation dans une certaine mesure. Et cela englobe nécessairement les systèmes associés, comme l'infrastructure réseau et les processus de sauvegarde informatique. L'Annexe 11 affirme simplement tout ceci plus clairement. Mais les attentes en matière de validation sont identiques dans les deux réglementations.
 
 
 
 

Nouveau webinaire

La cybersécurité dans votre système de surveillance GxP

La cybersécurité occupe une place croissante dans les applications réglementées par GxP qui font appel à des systèmes informatisés. Dans ce webinaire, nous expliquons comment le système de surveillance continue viewLinc de Vaisala utilise des fonctionnalités de sécurité avancées pour réduire l'exploitabilité des systèmes. Nous examinons les vulnérabilités logicielles, réseau et utilisateur courantes et les menaces affectant l'intégrité des données. Découvrez comment veiller à ce que vos systèmes offrent les contrôles et les procédures capables de sécuriser vos systèmes informatiques.
 
Objectifs d'apprentissage :

  • Procédures de sécurité
  • Vulnérabilités au niveau du chiffrement TLS (Transport Layer Security)
  • Types d'attaque : attaque par rejeu, attaque de l'intercepteur, SSL, JavaScript, attaque par force brute, etc.
  • Développement du support informatique et des fournisseurs
  • Fonctionnalités de sécurité des logiciels

En savoir plus et s'inscrire

Ajouter un nouveau commentaire