IEC 62304 +A1 – 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 faite 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é

Les règles changent avec l’amendement, en résumé : si le soft induit ou maitrise un risque acceptable il est en classe A; sinon B ou C selon le niveau de gravité.

La probabilité de bug doit être de 100% avant mise en œuvre de la norme.

On peut imaginer une approche plus fine, tenant compte de deux probabilités : probabilité d’avoir le bug qui induit la situation dangereuse (100%) et probabilité d’avoir la situation dangereuse et le dommage (pas forcément 100%), on a alors :

 

Gravité

Probabilité – – + ++
– – A A A A
A B C C
+ A B C C
++ A B C C

En complément :

  • Si du soft est utilisé pour maitriser un risque : le soft récupère la classe associée au dommage.
  • 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-A1-cycle-en-V

  • Plan de développement : qui, quand, comment, quels outils, … et la planification des activités exigées en fonction de la classe.
  • Spécification du logiciel: bien identifier les exigences et penser aux tests qui seront faits derrière (c’est le moment de commencer à les imaginer). S’il est suffisamment précis : le cahier des charge « projet » peut faire office de spécification des exigences.
  • Architecture : le dispatch des fonctions logicielles dans différents éléments logiciels, décomposés jusqu’aux 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 l’effort documentaire est limité : 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 maximum 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).
  • Si le bug est découvres en cours de développement : il est traité par l’équipe de dev, en utilisant les outils du plan de développement (typiquement : un gestionnaire de tickets)
  • 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.