Garantir la conformité de votre logiciel (de) dispositif médical à l’IEC 62304

Introduction

Si vous développez un dispositif médical qui utilise un logiciel, ou si vous développez un SaMD (Software as a Medical Device), il est important de comprendre et de respecter les exigences réglementaires applicables.

Les fabricants devraient s'intéresser à la norme IEC 62304 dès le début du processus de développement. Un problème courant est qu'il peut y avoir un décalage entre les développeurs brillants d’une part, la terminologie et les réglementations relatives aux dispositifs médicaux d’autre part. Cela peut se produire lorsqu'ils sont pris par la conception d'un nouveau logiciel génial, mais qu'ils ne s'intéressent pas aux exigences réglementaires à un stade précoce.

ADN vous propose un accompagnement dans l’implémentation des exigences de la norme CEI 62304 pour votre logiciel de dispositif médical ou SaMD.

Qu’est-ce-que l’IEC 62304 ?

La norme IEC 62304 : 2006 / AMD 1:2015 est la version actuelle de la norme internationale qui définit les processus du cycle de vie des logiciels utilisés dans les dispositifs médicaux. Cette norme est considérée comme une norme harmonisée et de ce fait est reconnue par les autorités réglementaires comme la Commission Européenne, la FDA et bien d’autres dans le monde.

Plus précisément, l’IEC 62304 s’applique à la fois au logiciel dispositif médical autonome (SaMD) et au logiciel intégré dans un dispositif médical final (SiMD).

Elle fournit des orientations pour la planification, le développement et les activités de surveillance après la mise sur le marché des logiciels de dispositifs médicaux. Elle doit être mise en œuvre dès le début de la phase de planification et doit se poursuivre après le lancement sur le marché.

Comment la CEI 62304 est-elle organisée ?

Le cadre de sécurité de l’IEC 62304 est censé être mis en œuvre en même temps qu'un système de gestion de la qualité (QMS) et un système de gestion des risques normalisé. Avec ces systèmes en place, l’IEC 62304 permet le développement et la mise en œuvre de logiciels en toute sécurité, au-delà des essais de produits et de l'analyse des risques.

Pour ce faire, elle définit trois classifications de sécurité pour les logiciels. Chaque classification comporte des exigences différentes en ce qui concerne la documentation relative au processus de développement. La norme est divisée en 9 chapitres. Les 4 premiers chapitres définissent le champ d'application de la norme ainsi que les références, les termes et les exigences générales. Les 5 chapitres suivants sont clefs pour le respect de la norme IEC 62304 :

• Chapitre 5 - Processus de développement des logiciels

• Chapitre 6 - Maintenance des logiciels

• Chapitre 7 - Gestion des risques liés aux logiciels

• Chapitre 8 - Gestion de la configuration des logiciels. Elle comprend le contrôle des modifications et le suivi de l'état de la configuration.

• Chapitre 9 - Résolution des problèmes logiciels

Classification de la sécurité des logiciels selon IEC 62304 ?

Il est important de garantir la sécurité dès le début du développement. Les tests de produits ne suffisent pas à garantir la sécurité des patients. Or, la sécurité des patients est essentielle. De plus, intégrer la sécurité dans vos processus dès le début permet d'économiser du temps et de l'argent par la suite.

La classification de la sécurité des logiciels dans la norme détermine les processus liés à la sécurité que vous devrez utiliser. Cela a une incidence sur l'ensemble du cycle de développement des logiciels, depuis les exigences et le codage jusqu'à la publication et la maintenance.

La norme définit trois classes de sécurité pour les logiciels dans son Chapitre 2 – Exigences générales

1. Classe A : aucune blessure ou dommage pour la santé n'est possible

2. Classe B : une blessure est possible, mais sans gravité

3. Classe C : La mort ou des blessures graves sont possibles.

La documentation requise pour le développement du processus du logiciel dépend de la classification de sécurité, comme indiqué dans le tableau ci-dessous.

Documentation	Class A	Class B	Class C
Development Planning	✔	✔	✔
Requirements analysis	✔	✔	✔
Architectural design		✔	✔
Detailed design			✔
Unit Implementation	✔	✔	✔
Unit verification		✔	✔
Integration & integration testing		✔	✔
System testing	✔	✔	✔
Release	✔	✔	✔
Maintenance	✔	✔	✔

Comment ADN vous accompagne ?

Pour se conformer à cette norme, les processus doivent être bien documentés. L'utilisation d'outils de gestion de cycle de vie logiciel tel que la suite Atlassian peut vous aider à répondre à ce besoin et à accélérer la mise en conformité.

Comment ? Prenons quelques exemples d’application pour chacun des 5 chapitres de la norme.

Chapitre 5 - Processus de développement des logiciels

Ce chapitre décrit les activités de développement logiciel à mener pour chaque classe de dispositif médical. L'utilisation d’Application de Gestion de Cycle de vie logiciel peut aider à répondre efficacement à ces exigences de documentation.

Exemples :

1. Les gestions des exigences et spécifications logicielles

Deux choses des plus importantes à penser en matière de conformité à la l’IEC 62304, est la gestion des exigences, spécifications logicielles et l’assurance de leur traçabilité. La plupart du temps, nous remarquons que les exigences se trouvent documentées dans un fichier Word, une feuille calcul Excel ou pour les plus chanceux sur un wiki. Il en va de même pour les spécifications. La seule façon d'assurer la traçabilité verticale dans ce cas est de mettre des numéros à côté de chaque exigence et spécification, puis de copier et coller librement ces numéros dans les deux documents et de voir les informations devenir ingérables et impossibles à maintenir très rapidement. Pour simplifier ce travail fastidieux, l'intégration de Jira et Confluence est une excellente solution.

Avec ses propriétés de tickets JIRA et leur type, vous pouvez créer des types de tickets à allouer à chaque niveau de spécification logicielle à savoir SRS, SAD, SDD sous Confluence. Les bénéfices et avantages visibles pour l'entreprise sont les suivants:

• Chaque exigence logicielle pourra être identifiée grâce à son type, mais surtout sa clé automatiquement générée lors de la création du ticket.

• De plus, Jira permet également d’établir des liens entre tickets. Le type de liaison permet par conséquent d'assurer la nature de la traçabilité entre exigences (couverture, dépendance, blocage, etc...). Ainsi, en explorant un ticket d'exigence on peut savoir duquel il découle et lesquels le couvrent.

• Un audit trail JIRA est automatiquement enrichi à chaque modification d'exigence.

• Les exigences sont également associées à une version logicielle.

• La spécification est générée automatiquement et mise à jour sous Confluence en s'appuyant sur un filtre JIRA.

2. Mise en place des tests

L’IEC 62304 spécifie la nécessité d'établir des tests pour les exigences logicielles. Plusieurs solutions existent pour répondre à ce besoin : Nous vous proposons le plugin « X-Ray » de JIRA permettant de générer des cas de test liés aux exigences. Les bénéfices et avantages visibles pour l'entreprise sont les suivants:

• Il crée un nouveau ticket de type « Test » auquel vous pouvez ajouter le bloc de texte standard ainsi que les différentes étapes de test que vous souhaitez. L'avantage de gérer vos tests sous JIRA est d'établir directement une traçabilité avec les exigences auxquelles ils sont liés.

• X-Ray dispose également du type « Test plan » pour créer des cycles de test. L’exemple typique est celui d’une version logicielle à la fin d’un sprint. L’idée est de créer pour chaque sprint ou version logicielle, un ou plusieurs plans de test où seront logés l’ensemble des cas de tests du sprint. Ces plans de test ont pour avantage de suivre les résultats de test du sprint/version et de présenter à un instant donné une vue d’ensemble schématisée de l’exécution des tests à titre de preuve pendant la phase de vérification du design produit.

• X-Ray permet de générer automatiquement une matrice de traçabilité entre les exigences, les tests, leur exécution et les bugs.

3. Processus de tests unitaires

Par ailleurs, les logiciels de classe B et de classe C doivent également établir un processus de vérification des unités logicielles. Vous pouvez satisfaire à cette exigence en utilisant les outils de couverture de code, d'analyse de code et de flux de données que propose votre plateforme de développement de logiciels (Gitlab, Bitbucket, etc...) dont l'intégration avec JIRA est possible pour harmoniser les données sur une même plateforme. Les bénéfices et avantages visibles sont les suivants:

• Visualiser le code associé aux tâches de développement

• Intégrer les activités de développement logiciel dans le planning global du projet

• Automatiser l'avancement des tâches de développement par rapport au résultat des tests unitaires

Chapitre 6 - Maintenance des logiciels

Date prévisible de publication: 29 Avril 2023

Chapitre 7 - Gestion des risques liés aux logiciels

Date prévisible de publication: 31 Mai 2023

Chapitre 8 - Gestion de la configuration des logiciels.

Date prévisible de publication: 30 Juin 2023

Chapitre 9 - Résolution des problèmes logiciels

Date prévisible de publication: 31 Juillet 2023

Conclusion

La norme IEC 62304 est l'un des piliers de notre système intégré de gestion de la qualité.

Notre équipe de consultants ingénieurs très expérimentée dans le développement de dispositifs médicaux SaMD et SiMD peut vous accompagner dans la mise en conformité à la norme CEI 62304 dans un environnement agile.

N'hésitez pas à nous contacter via le formulaire ci-dessous afin que nous puissions discuter de votre projet et des options qui s'offrent à vous.