IEC 62304, nouvelle révision : les évolutions
[article initialement publié le 25 octobre 2019]
La norme IEC 62304 édition 2 est, pour la seconde fois, en enquête publique, l’occasion de télécharger le document et de remonter vos commentaires à l’afnor.
Les changements depuis l’édition IEC 62304:2006+A1:2015 sont résumés ci-dessous.
Scope
Gros changement : la portée de la norme passe des dispositifs médicaux à l’ensemble des logiciels santé, aussi la norme distingue :
- les logiciels embarqués dans un DM ;
- les logiciels autonomes DM ;
- les logiciels embarqués dans un dispositif “de santé ; et
- les logiciels autonomes “de santé”.
Visualisation du cycle
Un nouveau schéma, plus clair, présente le cycle de vie définit dans la norme :
Recours aux autres normes
La norme s’arrête à la vérification du logiciel, la validation se fera :
- avec l’IEC 60601-1 pour un logiciel embarqué dans un DM
- avec l’IEC 82304-1 pour un logiciel autonome DM ou de santé
- avec la validation du produit pour un logiciel embarqué dans un produit “santé”
La gestion des risques utilise évidemment l’ISO 14971, l’ingénierie de l’aptitude à l’utilisation se fait selon l’IEC 62366-1.
Définitions
La norme reprend la définition de Logiciel de Santé déjà présente dans la norme IEC 82304-1:2016.
La notion de blessure grave (utilisée pour la classification du logiciel) est détaillée :
Blessure grave : blessure ou maladie qui
a) menace la vie ou cause la mort,
b) entraîne une carence permanente d’une fonction physiologique ou endommage de manière définitive une structure du corps, ou
c) nécessite une intervention médicale ou chirurgicale pour prévenir une carence permanente d’une fonction physiologique ou un endommagement définitif d’une structure du corps
La norme précise ce qu’elle attend par conformité :
La conformité au présent document est définie comme la mise en œuvre de tous les processus, activités et tâches identifiés dans le présent document en fonction de la classe de sécurité du logiciel.
La définition d’architecture évolue.
Finalement, les définitions sont complétées par Efficacité et Cybersécurité.
Gestion des risques
Cette partie est une des plus étoffée par la nouvelle révision de la norme, notez quelle reprend les éléments d’IAU sans les nommer (par exemple les erreurs d’utilisation et risques liés à l’utilisation sont à identifier dans l’analyse des risques selon l’IEC 62304)
Conformité de la gestion des risques
La norme le rend explicite : la conformité est déterminée par inspection du dossier de gestion des risques et des documents associés au cycle de vie du logiciel
Niveau de rigueur des “processus logiciels”
Cette nouveauté est dans l’esprit de l’approche par les risques de l’ISO 13485 (et de la na NF XP S99-223, en fait ce n’est pas tout fait nouveau : cela développe les notions déjà introduites par la gestion en classe de risque (A, B et C).
L’idée est, comme toujours dans le DM, de proportionner votre travail aux risques associés au produit.
Analyse des risques initiale
Le travail vous est mâché en précisant des items propres au logiciel que vous devrez traiter dans votre dossier de gestion des risques (profils utilisateurs, scénario utilisation…) et dans vos analyses des risques (la norme liste par exmple des défaillances logicielles classiques).
Classification du logiciel
Comme d’habitude, 3 classes :
- A si 0 dangers ;
- B si pas de dommages graves avec des mesures de maitrises des risques non logicielles ; et
- C sinon.
Plan de développement du logiciel
Une nouvelle exigence, vraisemblablement à destination des IA :
f) Le cas échéant, un protocole de modification d’algorithme pour la délimitation des données et procédures à suivre de sorte que les modifications d’algorithme satisfassent à l’objectif et que ledit algorithme reste sûr et efficace après modification. Les composants d’un protocole de modification d’algorithme à prendre en considération incluent la gestion des données, une nouvelle formation à l’algorithme, l’évaluation des performances de l’algorithme, ainsi que les procédures de mise à jour de l’algorithme.
Enregistrements des essais
Nouveau, il faut enregistrer :
Les enregistrements suffisants pour permettre la reproduction de l’essai.
Plan de maintenance
Le cycle de vie est considéré dans son intégralité, il faudra définir la stratégie de mise hors service du logiciel :
Une stratégie de retrait/mise hors service du logiciel, le cas échéant, y compris la gestion des données et la sécurité de l’information et la fin de l’accès au logiciel.