Finalité de la validation et de la traçabilité
Le but de la validation est de garantir qu’un processus ou un système est cohérent et documenté. La validation du système est une exigence des agences de réglementation. Pour les organisations des sciences de la vie, par exemple, les agences de réglementation comprennent la Food and Drug Administration (FDA) des États-Unis.
La FDA définit la validation comme suit :
Confirmation par examen et fourniture de preuves objectives que les exigences particulières pour une utilisation prévue spécifique peuvent être systématiquement remplies.
L’Organisation mondiale de la santé (OMS) définit la validation comme suit dans ses lignes directrices sur les exigences en matière de bonnes pratiques de fabrication (BPF) :
Établissement de preuves documentaires qui fournissent un degré élevé d’assurance qu’un processus planifié sera uniformément conforme aux résultats spécifiés attendus.
Ces définitions ont en commun les éléments suivants, conformément aux résultats attendus :
- Génération de preuves
- Conformité à la réglementation
- Satisfaction des exigences
La validation des systèmes informatisés est un processus documenté permettant de garantir que le système fait exactement ce pour quoi il a été conçu, de manière cohérente et reproductible. La validation garantit l’intégrité et la sécurité du traitement des données, la qualité des produits et le respect des réglementations applicables aux bonnes {industry} pratiques (GxP).
Le processus de validation d’un système informatisé est décrit dans les procédures opérationnelles standard (SOP) et les lignes directrices créées et définies par l’industrie réglementée, telle que les organisations des sciences de la vie. Pour la validation de systèmes informatisés, il est utile de considérer la mise en œuvre du processus comme un projet, tel que décrit dans le document de l’International Society for Pharmaceutical Engineering (ISPE) Bonnes pratiques de fabrication automatisées (GAMP) 5 : Une approche basée sur les risques pour des systèmes informatisés conformes aux normes GxP.
Avant de démarrer le projet de mise en œuvre, un plan de haut niveau pour la nouvelle solution doit être mis en place. Démarrez ensuite le projet en réalisant les phases suivantes :
- Planification : dans cette phase, les exigences et les spécifications doivent être suffisamment claires pour une première évaluation des risques et, finalement, pour une définition correcte des tests de vérification (protocoles). Au cours de cette phase, vous livrez le document du plan de validation qui définit l’ensemble de la stratégie de validation et tous les livrables. La stratégie doit être conforme au système de gestion de la qualité (QMS) et aux politiques.
- Spécification, configuration et codage : au cours de cette phase, toutes les spécifications de conception sont établies au niveau de détail requis par le type de système et son utilisation. Les développeurs choisissent et utilisent les méthodes et objets de développement les plus adaptés aux exigences de codage et de configuration et sur la base des spécifications approuvées. Toutes ces activités sont réalisées dans l’environnement de développement. Au cours de cette phase, les tests sont davantage axés sur la vérification des unités ou des fonctionnalités du point de vue du développeur. Des exemples d’activités de test incluent les tests unitaires, les tests statistiques du code et les tests d’intégration. Les outils peuvent automatiser ces activités de test.
- Tests : cette phase confirme que les spécifications ont été respectées grâce à des inspections et des tests du système. Les activités de test sont effectuées dans un environnement de test préparé et adapté. L’environnement de test doit ressembler à l’environnement de production pour garantir que les conditions sont les mêmes et que vous n’avez pas besoin de répéter les tests dans l’environnement de production. Le risque doit déterminer la portée de l’effort de test. L’analyse des risques peut vous aider à comprendre les dangers potentiels pouvant avoir un impact sur la qualité des produits, la sécurité des patients ou l’intégrité des données. Ces dangers potentiels doivent être atténués grâce à des contrôles en place et à des preuves de tests. S’il existe un risque élevé quelque part, disposez de scénarios de test appropriés pour prouver que la conception de la solution est sans défaillance potentielle.
- Rapports et publication : dans cette phase, le système doit être acceptable pour une utilisation dans l’environnement de production selon un processus documenté et contrôlé. À la clôture du projet, un rapport de validation du système doit être préparé pour résumer les activités entreprises et tout écart par rapport au plan de validation. La validation du système doit être terminée avant que le système soit mis en service.
L’illustration suivante montre le modèle V pris en charge par GAMP 5, 2e édition. Il offre une bonne manière globale de visualiser les phases du projet.
Le modèle en V peut être considéré non seulement comme les activités de développement et de test du système, mais également leur séquence, leurs interrelations et le processus de validation des livrables applicables au système informatisé validé. Vous devez conserver et entretenir les relations entre les exigences, les spécifications et les tests. Cette relation est documentée dans la matrice de traçabilité utilisée dans les zones réglementées.
La matrice de traçabilité garantit que :
- Les exigences sont remplies par la conception de la solution. En d’autres termes, chaque exigence est rattachée aux fonctions, contrôles, configurations ou éléments de conception.
- Les exigences sont testées ou vérifiées pour démontrer que la conception de la solution répond aux exigences, le cas échéant.
La matrice de traçabilité présente les avantages suivants :
- Il prend en charge la revue de conception.
- Cela permet de définir la portée des tests de régression.
- Il apporte un soutien lors des activités d’inspection ou d’audit.
- Il fournit un support pour les changements potentiels.
Qualification de la plateforme
Les industries réglementées doivent qualifier les Microsoft Power Platform comme infrastructure avant de mettre en œuvre les guides. La qualification de la plateforme nécessite au minimum les tâches suivantes :
Évaluation initiale des risques (évaluation de l’applicabilité des GxP)
Évaluation du fournisseur (audit d’un fournisseur, qu’il soit virtuel, physique ou postal)
Plan de qualification
Spécification technique de conception de la plateforme
Évaluation des risques (par exemple, évaluation du risque de mettre à disposition des opérateurs une mauvaise version d’un guide)
Essai :
- Tests d’installation (par exemple, tester que les environnements sont correctement installés)
- Tests opérationnels (par exemple, tester que les bons utilisateurs disposent des bons accès)
Rapport sommaire de qualification
Plate-forme ou manuel opérationnel et matériel de formation
Validation des candidatures
Applications (telles que les guides et Power Apps) qui prennent en charge les processus métier dans les secteurs réglementés doivent être validés. Par conséquent, votre organisation doit effectuer les tâches suivantes :
Évaluation initiale des risques
Plan de validation
Droits d’accès requis pour l’utilisateur
Évaluation des risques
Spécification fonctionnelle de l’application ou spécification technique de configuration
Tests (qualification d’installation [IQ], qualification opérationnelle [OQ] et tests d’acceptation utilisateur [UAT]) :
- Tests opérationnels (par exemple, vérification d’une fonction)
- UAT
Matrice de traçabilité
Rapport récapitulatif de validation
Manuel d’application ou opérationnel et matériel de formation