IEC 62304 – Logiciels de Dispositifs Médicaux- en bref

IEC 62304 en bref

(merci à Cyrille Michaud – alias M. 62304 – pour sa relecture).

1. Domaine d’application

Vous embarquez du soft dans un dispositif médical ? Vous codez un soft médical ?
Cette norme est pour vous.

2. Référence normative

Mettez en place en processus de gestion des risques selon l’ISO 14971.

3. Termes et définitions

  • Système : votre soft + le soft externe + le hardware autour.
  • Système logiciel : votre soft (embarqué dans un DM ou autonome).
  • Élément logiciel : le savant découpage de votre logiciel en gros, moyens et petits morceaux (découpage en µ-contrôleur, librairies, fichiers sources, fonctions, …).
  • Unité logiciel : les plus petits morceaux résultats du découpage. C’est vous qui en décidez la taille. La granularité doit permettre de vérifier le code de façon exhaustive.
  • SOUP : les softs tiers que vous utilisez (librairies, drivers, …) mais dont vous n’avez pas la preuve des performances.

4. Exigences générales

L’idéal est d’avoir un système qualité ISO 13485 pour prouver que l’on peut gérer 2/3 trucs critiques (surveillance post commercialisation, traçabilité, processus conception & développement, …)

Et utilisez la 14971, ça fait 2 fois qu’on le dit.

Classification de sécurité

Considérez le dommage patient en cas de bug :

  • Mort / Grave ⇒ C
  • Non grave ⇒ B
  • Rien ⇒ A

En complément :

  • Si une mesure de maitrise du risque hardware est appliquée : la classe baisse d’un cran.
  • Si du soft est utilisé pour maitriser un risque : le soft récupère la classe associée au dommage. (vous pouvez relire la phrase).
  • Un sous bout du code récupère la classe du code parent sauf si la séparation est démontrée :

62304-architecture-classe-de-securite

5. Développement

A chaque étape du cycle en V:

  1. Faire un plan.
  2. Faire une revue du plan.
  3. Appliquer le plan.
  4. Faire une revue des résultats.

Cycle en V

Le modèle de cycle de développement et l’applicabilité en fonction des classes sont résumés dans ce joli agréable nécessaire schéma :
IEC 62304 - 2006 - cycle en V

  • Plan de développement : qui, quand, comment, … les activités exigées en fonction de la classe.
  • Spécification du soft : bien identifier les exigences et penser aux tests qui seront faits derrière (c’est le moment de commencer à les imaginer).
  • Architecture : le dispatch des fonctions logicielles dans différentes unités logicielles. Une architecture bien conçue permet d’isoler les fonctions critiques (les classes élevées) dans du code / des micro-contrôleurs bien séparés du reste du soft (à démontrer). Du coup les dégâts sont limités : le code ‘risqué’ est traité en classe B/C, le reste en classe A/B. Ici aussi on imaginera les essais à faire derrière (intégration et non régression).
  • Conception détaillée : on détaille un max jusqu’aux fonctions de plus bas niveau, toujours en gardant à l’esprit qu’il faudra faire des tests.

Vous pouvez maintenant coder.

Viennent les tests :

  • Tests unitaires des unités logicielles.
  • Intégration et essais d’intégration et de non régression.
  • Essais fonctionnels.

Vous pouvez maintenant livrer (il y-a tout de même de la doc à générer, cf. §8)

6. Maintenance du logiciel

Concerne les modifications que vous ferez après livraison (correction de bug et ajout/modif de fonctionnalités en fonction des retours terrain, du client, du service marketing, …)

  • Consigner le retour d’info demandant/ nécessitant une modif du soft, votre processus de surveillance post market est là pour ça.
  • Évaluer si une modif est nécessaire (rappel: s’il y a un risque patient la réponse est oui), faire une demande de modif le cas échéant.
  • Évaluer la Demande De Modification (indice : analyser les risques).
  • Si modif acceptée : retour en case Développement avec une nouvelle exigence fonctionnelle à implémenter.
  • Informer vos clients / votre ON / votre autorité compétente, en fonction de la modif.
  • Diffuser.
  • Surveiller.

Un plan de maintenance doit expliquer tout ça.

7. Gestion des risques

Utiliser l’ISO 14971 (vous en doutiez encore ?) en tenant compte des SOUP (à valider. Surveiller les MAJ, les changelog, les bugs report, …), des autres éléments du système (hardware et soft externe), d’une mauvaise utilisation (coucou 62366-1), ….

8. Gestion de Configuration

On vous demande de conserver le nécessaire et suffisant pour pouvoir rejouer le développement et les tests : configuration logicielle, données de tests, configuration matérielle, …. sont à identifier et à archiver.

Un plan de gestion de configuration doit expliquer tout ça.

9. Résolution des problèmes

Alias: Processus de correction des bugs.

  • A lancer dès le développement (les premiers bugs sont mis en évidence lors des premiers tests).
  • Rédiger un rapport de problème : version du soft, nature du problème, conditions lors de la détection, effet sur le patient, recherche de la cause, …
  • Si bug après commercialisation : lancer le processus maintenance.
  • Coder un patch, mettre mettre en œuvre les modifs, vérifier : retour en Conception & Développement.