[2025-03-12] (Accès libre) La première édition de la norme IEC 62304 remonte à 2006, avec un amendement en 2015. L’édition 2 de la norme IEC 62304 pourrait être (enfin) publiée en 2027, après plusieurs rebondissements (voir, par exemple, notre article précédent).
Le groupe de travail de l’International Electrotechnical Commission a produit un guide accompagnant le projet de norme au stade « Committee Draft ». La publication de la norme est prévue en 2027.
Quels sont les principaux changements ?
- Extension du périmètre : le périmètre de la norme évolue. Elle s’applique désormais aux logiciels de santé et plus seulement aux dispositifs médicaux. Cela inclut notamment la gestion de la santé des personnes individuelles ou la prestation de soins ;
- Évolution des références : en conséquence du point précédent, la norme ne mentionne plus explicitement l’ISO 13485, ni l’ISO 14971. Cela amène plus de flexibilité au niveau des processus réglementaires et plus de cohérence au niveau du processus de gestion des risques. Cela ne signifie pas pour autant que les fabricants de logiciels qui sont en soi des dispositifs médicaux (en anglais, « Software as a Medical Device » ou SaMD, définis par un guide de l’IMDRF en 2013), ou les logiciels embarqués dans des dispositifs médicaux (« Software in a Medical Device » ou SiMD), ne soient plus en obligation d’appliquer ces référentiels ;
- Exclusion : les logiciels hérités sortent du cadre des exigences de la norme. Alors qu’ils étaient auparavant couverts dans la section 4, ils ont maintenant été déplacés vers une annexe. Peu de changements ont été apportés, à l’exception d’une brève explication sur la manière de gérer les logiciels développés sous les versions précédentes de l’IEC 62304, et en particulier la façon de traiter les logiciels de classe de risque B qui relèvent désormais du niveau de rigueur II. Dans ce dernier cas, des mises à jour significatives sont à prévoir pour se conformer à cette version.
Les points les plus impactants sont :
- Nouveau système de classification : la classification de sécurité devient un « niveau de rigueur » selon l’équivalence suivante :
- la classe A devient un niveau de rigueur I,
- les classes B et C correspondent au niveau de rigueur II.
- Renforcement des exigences dès le niveau I : la simplification du point précédent est compensée par une extension des exigences à prendre en compte dès le niveau I, en particulier sur l’architecture et sur la validation des outils et méthodes ! Ceci vise notamment à répondre aux exigences de cybersécurité.
- Exigences spécifiques pour les logiciels embarquant de l’Intelligence Artificielle (IA) (« Artificial Intelligence as a Medical Device » ou AIaMD), avec des processus spécifiques à mettre en place :
- Planification du processus d’IA, selon un cycle de vie (« Development Lifecycle » ou AIDL)
- Plans et rapports de vérification et validation de l’IA
- Planification de l’évaluation des performances de l’IA
- Certaines exigences sont clarifiées au niveau des attendus de la maintenance (plan de maintenance du logiciel à initier très tôt dans le cycle de développement du logiciel).
Il est essentiel de surveiller de près les évolutions de ce projet de norme, car certains de ces changements auront un impact majeur sur la documentation technique et la conformité.
Article rédigé par Olivier TOURDES, membre du réseau DMEXPERTS