Depuis bientôt 20 ans DELTENRE CONSULTING SPRL s’est spécialisé dans la validation des systèmes informatiques supportant l’industrie pharmaceutique. Fort de notre expérience nous avons créé des « standard operating procedures » et templates de documents de validation utilisable dans toutes les industries pharmaceutiques.
Qu’est ce qu’un Système informatisé ?
Un Système Informatisé (Computerized System) est un système informatique supportant un processus de travail, une fonction.
Qu’est ce que la Validation de Systèmes Informatisés ?
La validation de Computerized System consiste à documenter qu’un système répond de manière cohérente à un ensemble de conditions prédéfinies.
La validation des Computerized Systems garantit l’exactitude, la fiabilité, la performance attendue et la capacité à discerner des enregistrements non valides ou altérés.
Pourquoi est-ce important ?
La CSV prévient les problèmes de softwares avant qu’ils atteignent l’environnement d’utilisation. Ces dysfonctionnements peuvent avoir de graves conséquences négatives directes ou indirectes sur le patient. Cela pourrait entraîner des poursuites, des amendes ou la mise à l’arrêt.
Ne pas effectuer certaines validations de Computerized Systems en accord avec les Best Practices serait contraire aux règlements (p. ex., les exigences obligatoires en matière de conformité des documents électroniques, telles que décrites dans la FDA 21 CFR 11.10a et EMA Annexe 11, section 4).
La validation informatique est indispensable pour l’enregistrement des médicaments et vaccins, c’est un des critères de recevabilité des dossier d’AMM (autorisation de mise sur le marché). Aujourd’hui, ne pas valider un système, c’est se mettre hors la loi.
Quels sont les avantages de la validation ?
La validation permet:
- la réduction des coûts de développement d’un système en permettant une détection rapide et efficace des erreurs de conception.
- d’augmenter les chances d’obtenir un projet performant
- la réduction des coûts de maintenance des systèmes
- la diminution des menaces de suspension ou d’interdiction de produire
- la diminution des coûts d’échantillonnage et de contrôle
- l’amélioration des flux de production
Ne pas valider peut coûter très cher, d’une manière générale il faut souligner que le coût d’une prévention est toujours fortement inférieur au coût d’une réparation. Le budget validation, en terme de ressources alluées à un projet est de l’ordre de 20%. Certaines sociétés pharmaceutiques l’ont évalué à moins de 5% en tenant compte des bénéfices générés par le système validé.
Comment se déroule la validation ?
La validation d’un système informatisé se déroule en 5 phases distinctes: la préparation, la définition des besoins, la création du système, la vérification du système, le reporting et la release.
Phase 1: La préparation
La préparation est la phase d’initiation de la validation, dans cette phase, le planning, les ressources et les documents nécessaires à la validation du système informatisé sont définis dans le plan de validation. Les rôles et responsabilités sont également définis. Si on valide un système commercial acheté chez un fournisseur, on audit ce dernier pour vérifier son système qualité. On analyse également l’intention d’usage du système informatisé (endroit du cycle produit où il est utilisé, processus supporté, etc…) afin de connaître l’effort de validation à fournir.
Phase 2: La définition du blueprint
Dans cette étape, on capture précisément le besoin : « Que doit faire le système informatisé ? » , le besoin est consigné sous forme de requis atomiques dans le cahier des charges ou URS (User Requirement specification). On analyse ensuite comment répondre au besoin en créant les spécifications fonctionnelles (FS) et les spécifications de design (DS). Ces 2 documents définissent le fonctionnement interne du système et la manière dont il est intégré dans l’architecture informatique de la société. On notera que sur base des différentes fonctions identifiés dans la FS et sur base des composants d’architecture identifiés dans la FS, on peut réaliser une analyse de risques (identification des fonctions et composants les plus à risque).
Phase 3: Configuration / Coding
Dans cette étape, le système va être développé sur base des documents FS et DS établis à l’étape précédente. Si le système est acheté tout fait chez un fournisseur, il sera installé et configuré dans cette étape. Généralement lors de cette étape on travaille avec plusieurs environnements. Un environnement de test qui permet au développeur de tester sa solution jusqu’à ce qu’elle soit stable et fonctionnelle. Un environnement de validation qui permet d’exécuter les protocol officiels de testing pour assurer la validation du système. Et un environnement de production qui sera l’environnement officiel d’utilisation du système en routine.
Phase 4: Blueprint verification
Durant cette phase, on va exécuter les protocols de vérification IQ, OQ, PQ et si nécessaire MQ, ces derniers permettront de confirmer que le système est correctement installé, fonctionne tel qu’attendu et supporte de façon adéquate le processus pharmaceutique sous jaccent. Ainsi, l’installation qualification (IQ) permet de vérifier que les différents composants d’architecture (software, hardware, database, etc…) sont installés en adéquation avec les spécifications de design. L’operational qualification (OQ) permet de vérifier que les fonctions du système sont développées en adéquation avec les besoins. La performance qualification (PQ) permet de vérifier que le système fonctionne de façon adéquate au sein du business process (chaine de production, laboratoire, gestion d’étude clinique, etc…). Dans certains cas, si des anciennes données doivent être déplacées d’un ancien système vers le nouveau, une vérification de la migration des données (MQ – Migration Qualification) peut s’avérer nécessaire (vérification de la complétude de la migration de données et que le système fonctionne correctement avec les anciennes données migrées). TOus les protocols de tests IQ,OQ,PQ et MQ sont basés sur les risques identifiés au niveau des composants, des fonctions , du process et des données.
Phase 5: Reporting & Release
Dans cette phase, on établi le rapport de validation, ce dernier vérifier que tous les documents identifiés lors des différentes phases ont bien étés produits et signés. Si certains documents sont manquants, une justification avec un rationnels est émises pour expliquer l’absence du document (exemple: pour un système excel qui tient dans un fichier unique, il ne faut pas de design specification car il n’y a pas besoin d’architecture sous-jaccente (si ce n’est un système de fichiers). Dans le rapport de validation, on vérifie également que les critères d’acceptance définis dans le plan de validation sont bien rencontrés. Généralement, il s’agit du fait que l’ensemble des documents ont été produits, que les protocol de test ont été exécutés avec succès et qu’aucune non-conformité bloquante n’a été identifiée.