L’évolution ponctuée de la validation des logiciels informatiques

L’état exact de la validation des logiciels informatiques (CSV) peut être difficile à cerner. Alors que les initiés de l’industrie peuvent le qualifier de lent à changer, tenter de trier diverses procédures, approches et technologies complexes pour développer un processus véritablement validé peut être déroutant pour ceux qui regardent de l’extérieur.

Pour remédier à cette ambiguïté, Technologie pharmaceutique s’est entretenu avec G. Raymond Miller, PhD, directeur de cours pour la validation des systèmes informatiques au Centre pour l’innovation et l’éducation professionnelles. Miller a abordé divers sujets, notamment l’essor de l’assurance des logiciels informatiques (CSA), la manière de contextualiser les nouveaux projets de directives des autorités de réglementation et les problèmes courants liés aux CSV.

Adopter des approches alternatives

PharmaTech: La FDA a récemment rédigé un projet de directives sur la CSA qui décrit une nouvelle approche de validation. Comment cela fonctionne-t-il, en quoi diffère-t-il des approches historiques et pourquoi la FDA l’applique-t-elle ?

Meunier: Premièrement, la CSA ne remplace pas la validation informatique ; c’est une approche alternative au processus qui a évolué depuis le milieu des années 1980. Pendant des décennies, CSV a été un effort dans les bonnes pratiques de documentation. Le résultat a trop souvent été une documentation parfaite qui n’a pas grand-chose à voir avec le bon fonctionnement du système et qui finit par être enfermée au cas où un enquêteur le demanderait. L’intention de la CSA est de se concentrer davantage sur les opérations système difficiles de la manière dont nous avons l’intention de les utiliser, et non de produire des piles de documentation magnifique mais dénuée de sens.

En tant que FDA Principes généraux de la validation logicielle souligne (1), le logiciel ne s’use pas ; étant donné les mêmes entrées, il fournira la même sortie. Les résultats des opérations informatisées peuvent varier lorsque les entrées changent. Nous n’avons pas besoin d’exécuter un test plusieurs fois avec les mêmes entrées ; nous devons injecter une variété d’entrées destinées à générer des erreurs si nous le pouvons. Nous voulons le casser pendant les tests, pas en production, lorsque des erreurs pourraient nuire directement au public, ou peut-être par d’autres impacts tels que la perturbation des activités. CSA représente la réflexion actuelle sur la façon de rendre le processus CSV à valeur ajoutée.

En ce qui concerne les défis de la CSA dans les tests, j’essaie toujours de comprendre les tests sans preuves révisables. Non pas à cause d’un besoin perçu de preuve, mais pour surmonter la nature humaine et emprunter la voie de la facilité. Disons que c’est vendredi après-midi, nous étions fatigués et prêts à partir pour le week-end. Nous pourrions être un peu moins diligents pour remarquer et enquêter sur une anomalie qui se produit pendant les tests ; surtout si nous ne sommes pas tenus d’avoir des preuves documentées. J’ai vu cela se produire trop de fois au fil des ans. Si nous devons avoir des preuves documentées et signer nos actions, nous ne pourrons pas contourner les procédures et ignorer ces écarts. Comment pouvons-nous nous concentrer davantage sur les tests tout en garantissant une diligence raisonnable ?

Des conseils en tête ?

PharmaTech : Le Centre des appareils et des contrôles radiologiques (CDRH) a également établi une liste de directives prévues pour 2023 pour la validation informatique de divers appareils (1). D’une manière générale, quels sont certains des principaux changements que nous pouvons attendre de ces orientations ? Comment les entreprises s’y préparent-elles ?

Meunier: Mes intérêts sont dans le processus CSV lui-même ; Je le vois comme juste du bon IT [information technology] pratiques commerciales, donc cela s’applique vraiment à tous les niveaux. Les conseils dans la liste des CDRH qui se démarquent pour moi sont la cybersécurité dans les dispositifs médicaux. Je vois cela comme une prise de conscience documentée de l’impact sérieux de la cybersécurité sur la sécurité des patients.

Mais je pense également que la réflexion actuelle a des implications plus larges pour CSV en général, un accent accru sur l’analyse des dangers, l’atténuation des risques et les tests de scénarios concernant la cybersécurité et l’intégrité des données. L’identification des fonctions prévues pour la validation devrait inclure des fonctions destinées à atténuer les dangers grâce à la gestion des risques, y compris des tests plus robustes. Ce ne sont que de bonnes pratiques commerciales informatiques. Les entreprises doivent construire de manière proactive des systèmes contrôlés de manière appropriée, sans attendre que les documents d’orientation soient finalisés pour commencer à planifier des actions.

Contextualiser les changements de l’industrie

PharmaTech: Décririez-vous la validation par ordinateur comme un segment de l’industrie pharmaceutique qui connaît régulièrement des changements significatifs dans la technologie ou les approches, ou est-ce plus incrémental ? En dehors des changements décrits par la FDA, connaissez-vous des technologies ou des approches récentes qui modifient la manière dont la validation informatique est gérée ?

Meunier: Je le décrirais comme une évolution ponctuée. Il y a une peur du changement, alors les entreprises s’en tiennent à l’héritage, c’est-à-dire à la validation axée sur la documentation, juste pour être sûr ! Ils attendent que les autres montrent qu’il est d’accord pour évoluer. Souvent, la perspective est qu’il n’y a qu’une seule façon de valider parce que, c’est comme ça que nous l’avons fait dans la société XYZ. Nous devons cultiver la conscience de la nécessité de nous adapter au fait que différents systèmes nécessitent des approches différentes : les applications accessibles par navigateur, basées sur des bases de données par rapport à l’acquisition de données, et les applications de traitement par rapport aux applications de contrôle de processus en temps réel sont trois catégories générales qui ont des approches de validation différentes.

Dans cette veine, l’accent est moins mis sur tout ce que nous voulons qu’un système fasse et se déplace plutôt vers les utilisations prévues autour de l’intégrité des données et des risques de sécurité. Nous avions l’habitude de revalider si nous déplacions un instrument d’une paillasse à une autre. Aujourd’hui, nous ne pouvons pas valider un changement qui n’affecte qu’une interface utilisateur graphique s’il n’y a pas d’impact sur l’intégrité et la sécurité des données.

Comprendre l’examen périodique

PharmaTech: L’examen périodique des systèmes de bonnes pratiques (GxP) n’est souvent pas pris en compte dans les discussions entourant la validation informatique. Pourquoi est-ce nécessaire, en quoi diffère-t-il de la validation initiale et comment est-il pris en compte dans le cadre plus large de la réalisation de la validation ?

Meunier: Je suis surpris que l’examen périodique ne soit pas considéré comme faisant partie des procédures d’exploitation et de maintenance après la mise en œuvre ! La validation consiste à s’assurer qu’il existe des contrôles procéduraux autour du fonctionnement et de la maintenance des systèmes pendant leur utilisation. Les GXP s’attendent à ce que les personnes soient formées sur ces procédures avant d’être autorisées à utiliser les systèmes informatisés. Annexe 11 de l’UE pour les BPF [good manufacturing practices] et Q7 pour les API traitent tous deux d’un examen périodique.

Le concept est qu’une fois qu’un système est validé pour une utilisation dans des opérations réglementées, il devrait y avoir des procédures pour le maintenir dans l’état validé. Le contrôle des changements est une procédure : un changement ne peut être effectué sans une évaluation de l’impact du changement et des activités de validation appropriées pour remettre le système dans son état validé si le changement est autorisé à se poursuivre. Le concept d’examen périodique est davantage une assurance qualité [quality assurance] activité pour évaluer l’efficacité des procédures d’exploitation et de maintenance, et s’il existe des preuves que le système pourrait ne plus fonctionner dans l’état validé. Toute divergence doit être documentée et une action de contrôle des modifications initiée pour résolution. L’examen périodique n’aboutit pas souvent à une revalidation à moins que les procédures de contrôle des modifications ne soient pas suivies.

Isoler les points douloureux

PharmaTech: Quels sont les problèmes les plus courants dans la validation informatique ? Qu’est-ce qui est fait, le cas échéant, pour les résoudre?

Meunier: L’un est la culture d’entreprise : il y a une date de livraison ciblée, mais le projet connaît trop de retards. De moins en moins de temps est disponible pour les tests et la finalisation. Une gestion de projet efficace dès le départ permet aux parties prenantes de savoir que le non-respect des procédures entraînera des retards dans le calendrier, et non des actions inférieures aux normes.

Quelque chose que j’ai également vu fréquemment est que l’AQ n’est pas intégrée au processus tant que le projet n’est pas dans sa phase finale. Il y a soit la nécessité d’arrêter les progrès pour les corrections, soit la pression pour que l’AQ adhère et approuve à contrecœur. La prévention vient des procédures et de l’éducation sur l’importance de suivre les procédures. J’ai dit à certains dans le passé que la validation rétrospective n’est que la reconnaissance que les procédures appropriées de validation et de cycle de vie du développement logiciel n’ont pas été suivies depuis le début.

Un autre est des tests inadéquats tels que des défauts graves sont rencontrés à un stade tardif ou même dans la production. Cela peut être atténué par l’analyse des dangers et la gestion des risques dès l’étape des exigences. Utilisez les résultats pour définir de manière proactive les tests et les ensembles de données prévus pour détecter les problèmes avant que l’impact ne s’aggrave.

Enfin, attendre que la validation soit en grande partie terminée pour préparer le rapport de synthèse. Les gens doivent relire et résumer les actions, ce qui entraîne de longs délais de livraison et une pression pour libérer le système, ce qui entraîne des retards encore plus importants dans le rapport de synthèse. Au lieu de cela, rédigez les sections du rapport de synthèse au début et complétez-les au fur et à mesure de la validation. Dès que la dernière action est terminée, il n’y a qu’un seul élément à compléter dans le rapport de synthèse et il est prêt à être approuvé, libérant le système pour une utilisation dans les opérations réglementées.

Réflexions finales

PharmaTech: Avez-vous d’autres réflexions que vous aimeriez partager sur la validation informatique ?

Meunier: Une dernière recommandation que j’ai faite au fil des ans et où les concepts CSA ont déjà un impact sur les tests : écrire des cas de test pour dire au testeur quoi faire, pas comment le faire ! Les pratiques d’écriture de cas de test héritées obligent les auteurs de test à parcourir le logiciel, en enregistrant les étapes qu’ils ont dû suivre pour tester le système (cas de test fortement scénarisés). Il y a beaucoup de problèmes avec ceci :

Cependant, tester devant le logiciel teste ce qu’il fait, pas ce qu’il devrait et ne devrait pas faire. Cela nécessite généralement de parcourir le scénario pour que les étapes soient écrites correctement, et les tests de simulation prennent ensuite du temps pour s’assurer que le cas de test a été écrit correctement. Ensuite, le cas de test est examiné et approuvé par d’autres avant de pouvoir finalement être exécuté par quelqu’un d’autre, pour la documentation officielle du test. Il n’y a aucune valeur à exécuter à sec les cas de test ; les éliminer permet d’économiser beaucoup de temps et d’efforts.

Et si nous écrivons le cas de test à partir de l’évaluation des risques des exigences en indiquant au testeur quoi faire mais pas comment le faire, nous obtenons de nombreux avantages. Parce qu’en testant ce que nous avons l’intention de faire, sans confirmer ce qu’il fait réellement, nous avons une meilleure chance de trouver des défauts. Il n’y a pas non plus d’étapes de navigation de test écrites de manière incorrecte ou d’exécution douteuse, de sorte que les erreurs sont généralement de véritables problèmes système. De plus, les auteurs de test peuvent écrire les cas de test pendant que le système est en développement, les cas de test peuvent éventuellement être utilisés pour diriger le développement ou atténuer les problèmes à l’avance, et le testeur est libre d’explorer le fonctionnement du système au fur et à mesure que le test progresse et de suivre vers le bas des anomalies.

Ce ne sont que mes réflexions actuelles sur la validation informatique à partir de l’expérience de plusieurs centaines de projets de validation informatique au fil des ans. Tout le monde ne sera pas d’accord avec eux, mais j’espère qu’ils en examineront les mérites et proposeront des alternatives utiles. Je suis toujours ouvert aux nouvelles approches et aux processus améliorés dans le but général de maintenir les validations de systèmes informatiques pratiques mais défendables.

Les références

1. FDA. Principes généraux de validation de logiciels ; Directives finales pour l’industrie et le personnel de la FDA (CDRH et CBER, janvier 2002).

2. FDA. Orientations proposées par le CDRH pour l’exercice 2023 (CDRH, octobre 2022).

A propos de l’auteur

Grant Player est l’éditeur associé de Technologie pharmaceutique.

Détails de l’article

Technologie pharmaceutique
Vol. 47, n° 2
Février 2023
Page : 32-33

Citation

Lorsque vous faites référence à cet article, veuillez le citer comme G. Playter. L’évolution ponctuée de la validation des logiciels informatiques. Technologie pharmaceutique2023 47 (1).