Validation des logiciels utilisés dans le SMQ

Nouveauté de la norme ISO 13485:2016, il faut désormais valider les systèmes informatisés utilisés dans le cadre du SMQ, une exigence que l’on retrouve :

• § 4.1.6 : logiciels utilisés dans le SMQ (au sens large)
• § 7.5.6 : logiciels utilisés dans le cadre de la production ou des prestations de service
• § 7.6 : logiciels utilisés dans le cadre de la surveillance / mesure (du produit ou de vos activités)

Cet article présente l’approche attendue pour de telles vérifications, en accord avec le guide ISO TR 80002-2.

Pourquoi une validation des logiciels ?

Première réponse : pour éviter les non-conformités. C’est une nouveauté et ce point est particulièrement suivi lors des audits ISO 13485:2016.

Seconde réponse : pour éviter une catastrophe industrielle :

• Le logiciel de contrôle final des dispositifs donne des faux positifs ? Il faut rappeler tout le lot
• Le logiciel de suivi des ECM se trompe dans l’état de conformité métrologique ? Il faut faire une analyse d’impact sur tous les dispositifs contrôlés avec l’ECM
• Le logiciel de gestion des documents n’est pas robuste ? Attendez une fausse manip’ dans les dossiers de la documentation technique …

Nous confions de plus en plus de responsabilités aux logiciels, ils doivent être validés en conséquence.

Validation des logiciels selon l’ISO TR 80002-2

Le guide ISO/TR 80002-2:2017 est disponible en anglais uniquement, il n’y-a pas d’éditions nationales (voir les boutiques de normes).

Remarque : le guide s’applique aux logiciels du SMQ, les logiciels dispositifs médicaux ou faisant partie d’un dispositif médical ne sont pas concernés, ils ont leur propre norme (l’IEC 62304)

Vue globale des activités

Le logigramme ci-dessous met en évidence les activités de définition du contexte, gestion des risques, planification et validation durant les phases de conception, développement et maintenance.

Cycle de vie des logiciels

Le guide aborde deux types de logiciels :

1. les logiciels achetés
2. les logiciels développés en interne

Le cycle de vie du logiciel couvre les activités de :

1. Conception, dans le cas des logiciels achetés cela se limite à définir le contexte : à quoi sert le logiciel, qui va l’utiliser, quels sont les risques associés
2. Développement (pour les softs faits en interne)
3. Maintenance (modification d’un logiciel réalisé en interne ou mise à jour d’un logiciel sur étagère)

Validation des logiciels

La planification de la validation d’un logiciel est réalisée dès la définition du besoin, elle repose sur l’analyse des risques associée à l’utilisation du soft :

1. identifier les risques propres à l’activité utilisant le logiciel (ex : risque de perdre la traçabilité d’un dispositif)
2. identifier les risques induits par l’outil logiciel (ex : risque de mauvais accès à une base de données)
3. évaluer les niveaux de risques
4. en fonction du niveau de risque : planifier la validation

Il n’est pas question de faire une vérification technique du logiciel, mais de valider l’atteinte des objectifs d’utilisation, en déroulant des scénarios d’utilisation avec des utilisateurs représentatifs.

Approche par les risques appliquée à la validation de logiciel

La norme ISO 13485 prône une approche basée sur les risques. Il est inutile de tout valider et de tout tester pendant des mois pour un coût exorbitant, un volume documentaire énorme et un résultat déjà connu.

L’effort doit être proportionnel à la criticité du système.

Pourquoi faire compliqué alors que c’est souvent si simple ?

Validation des logiciels et RGPD

Pour s’adapter aux nouvelles réalités numériques l’Europe a amélioré son cadre législatif avec l’entrée en vigueur du RGPD le 25 mai 2018.  Tous les organismes sont concernés, publics et privés, de tout secteur d’activité : ils doivent obligatoirement assurer une protection des données et être en mesure de le démontrer la conformité réglementaire des logiciels concernés.

Une analyse d’impact sur la protection des données doit être menée, au regard des risques pour les droits et libertés des personnes concernées.

Conclusion

Le processus de validation fournit une preuve documentée des performances des logiciels que vous utilisez dans vos activités les plus critiques.

Une définition claire des documents maîtres (Cahier des charges, Spécifications Fonctionnelles et Techniques, Plan de Validation, Analyse de Risque et Matrice de Traçabilité) et une planification des tests réalisés permettront de réduire la phase de test de validation à son minimum et ainsi économiser un temps précieux.