CSV selon GAMP 5 (2e édition) : moins de documentation, plus d'intégrité des données

La validation des systèmes informatisés a mauvaise réputation : trop souvent, elle se résume à des piles de scripts de test que personne ne lit. La deuxième édition de GAMP 5 fait le ménage et remet l'objectif réel au premier plan, à savoir une intégrité des données solide pour un effort proportionné. Le cadre n'est pas nouveau, mais il est mené jusqu'au bout avec plus de rigueur.

Le risque pilote l'effort

Le cœur reste l'approche fondée sur le risque. Trois questions sont déterminantes : que signifie une défaillance pour le patient, pour la qualité du produit, pour l'intégrité des données ? Si la réponse est anodine, on travaille de manière allégée. Si elle ne l'est pas, on teste en profondeur. L'erreur typique des projets n'est pas un effort insuffisant, mais un effort réparti uniformément.

Catégorisation et levier fournisseur

L'affectation aux catégories logicielles GAMP détermine la voie à suivre : infrastructure (1), logiciel standard non configuré (3), produits configurés (4) et développement spécifique (5). Plus on est haut dans cette échelle, plus il est possible de s'appuyer sur le travail du fournisseur, pour autant qu'une évaluation qualifiée le justifie.

• Déterminer la catégorie avant de tester, et non après.
• Évaluer et exploiter la documentation du fournisseur au lieu de la reconstituer.
• Tester ce qui porte le risque, et non ce qui est facile à tester.

Ce que la deuxième édition change réellement

Trois points sont repondérés. Le développement itératif et agile est traité comme un cas normal et non comme une voie dérogatoire. Les modèles cloud et service disposent de leur propre espace, avec la question de ce que fournit le prestataire et de ce qui reste sous sa propre responsabilité. Et l'intégrité des données n'est plus un chapitre annexe, mais une exigence de conception. La FDA poursuit la même orientation avec le Computer Software Assurance.

Critical Thinking plutôt que des modèles

La nouveauté la plus importante est culturelle. Ce sont des ingénieurs qui réfléchissent qui sont attendus, et non des personnes qui remplissent des formulaires. Un cas de test qui n'existe que parce que le modèle prévoit une ligne pour lui coûte du temps et ne prouve rien. À l'inverse, un contrôle bref et bien argumenté vaut davantage que vingt pages de justificatifs sur une fonction non critique. Ce qui est exigé, c'est la justification, pas le volume.

Moins de documentation, plus d'intégrité des données : ce n'est pas une contradiction, mais l'objectif.

Le cycle de vie commence après la mise en service

La validation ne s'arrête pas à la PQ. Les modifications passent par le change control, la revue périodique vérifie si les hypothèses tiennent toujours, et la sauvegarde des données ainsi que leur restauration ne doivent pas être affirmées, mais testées. La fin en fait également partie : lorsqu'un système est remplacé, il faut avoir clarifié comment les données resteront lisibles pendant toute la durée de conservation. Les remplacements achoppent plus souvent là-dessus que sur la migration elle-même.