Le développement de dispositifs médicaux est un processus englobant des tâches complexes et les erreurs de conception peuvent avoir des conséquences majeures sur les patients. Il est donc primordial de mettre en place des processus garantissant une qualité élevée, mais également une gestion efficace des risques pour les patients et leurs utilisateurs.
Une introduction rapide aux normes relatives aux dispositifs médicaux
Pour éviter que cela ne se reproduise, les gouvernements ont instauré des réglementations. Ils ont ensuite confié à des agences gouvernementales, comme la Food and Drug Administration (FDA) aux États-Unis et Santé Canada, la responsabilité d’approuver les nouveaux produits médicaux. Ces dernières ont alors défini des réglementations (regulation) pour donner des instructions détaillées sur la manière dont les lois doivent être appliquées. Bien qu’elles doivent avant tout préciser ce qui est exigé des fabricants, une grande partie de leurs exigences proviennent en fait de différentes normes internationales.
Les normes (standards) sont des références qui décrivent une manière de faire à la fois approuvée et reconnue. Elles ont été pensées par des experts qui connaissent les besoins des organisations qu’ils représentent (fabricants, associations, régulateurs, etc.). Bien que le respect de ces normes soit volontaire, de nombreux régulateurs y voient une preuve de «bonnes pratiques». De plus, plusieurs réglementations s’appuient explicitement sur des normes reconnues par l’industrie.
Qu’est-ce que la norme IEC 62304?
La norme IEC 62304 intitulée Logiciels de dispositifs médicaux – Processus du cycle de vie du logiciel (Medical device software – Software life-cycle processes) est une norme internationale qui définit les exigences relatives au cycle de vie des logiciels de dispositifs médicaux, dont le développement et la maintenance. L’ensemble des processus, activités et tâches décrits dans la norme établit un cadre commun qui va de la planification initiale jusqu’au déploiement et à la maintenance de l’appareil, en passant par l’analyse des besoins et le test du logiciel.
La classification du logiciel détermine les activités à effectuer
- Classe A: Aucune blessure ou atteinte à la santé du patient n’est possible.
- Classe B: Des blessures sont possibles, mais sans gravité.
- Classe C: Des blessures graves pouvant entraîner la mort sont possibles.
| Documentation du logiciel | Classe A | Classe B | Classe C |
|---|---|---|---|
| Software development planning | ✅ | ✅ | ✅ |
| Software requirement analysis | ✅ | ✅ | ✅ |
| Software architectural design | - | ✅ | ✅ |
| Software detailed design | - | - | ✅ |
| Software unit implementation | ✅ | ✅ | ✅ |
| Software unit verification | - | ✅ | ✅ |
| Software integration & testing | - | ✅ | ✅ |
| Software system testing | ✅ | ✅ | ✅ |
| Software release | ✅ | ✅ | ✅ |
Des activités en lien avec le système de gestion de la qualité (SGQ)
Ceci dit, la norme IEC 62304 ne vit pas en silo. Elle s’insère dans le cadre d’autres exigences et normes de l’industrie. C’est le cas, par exemple, de la norme ISO 13485 intitulée Dispositifs médicaux – Systèmes de gestion de la qualité (Medical devices — Quality management systems). Cette dernière décrit les exigences des systèmes de gestion de la qualité. Elle s’applique au développement des dispositifs médicaux, mais elle n’est pas spécifique à une discipline particulière (mécanique, électronique, logiciel, etc). C’est la norme IEC 62304 qui vient compléter la norme ISO 13485 avec des requis spécifiques au développement logiciel.
Pour mieux comprendre, le système de gestion de la qualité (SGQ) est un guide qui prend la forme d’un cadre de travail structuré. Il est mis en œuvre par les organisations pour que leurs produits et services soient de qualité constante, mais aussi conformes aux réglementations. Il désigne l’ensemble des politiques, processus, procédures et ressources nécessaires pour planifier, exécuter et contrôler le développement des produits et services d’une organisation.
La norme ne précise pas comment les activités doivent être faites
La norme IEC 62304 définit les activités qui doivent être faites, mais ne précise pas quand ni comment. Chaque organisation doit donc documenter ses processus et ses activités, et les détailler dans les procédures opérationnelles normalisées (Standard Operating Procedures ou SOP) du SGQ.
D’ailleurs, bien qu’elle semble promouvoir une approche «waterfall», la norme IEC 62304 n’impose ou n’exclut aucune méthodologie de développement. Elle présente les activités de manière linéaire par simplicité de compréhension. C’est donc à l’organisation ou à l’équipe de décider et de définir l’approche qui sera mise en œuvre.
Le plan de développement logiciel: un document essentiel
La norme IEC 62304 exige que chaque activité soit planifiée et documentée. Pour cela, le plan de développement logiciel (Software Development Plan) est un document essentiel à garder en référence tout au long du processus.
Le plan de développement logiciel établit et documente le processus de développement prévu au projet. Il vient définir le cycle de vie du développement, en établissant des phases et en y associant les activités et livrables qui doivent être effectués, incluant ce qui doit être documenté, les rôles et les responsabilités, ainsi que les jalons et dates importantes. Son écriture prouve donc qu’une planification du développement a bien été effectuée et guide l’équipe projet tout au long du développement.
La norme doit être associée avec les recommandations de la FDA
Ceci dit, la norme IEC 62304 ne couvre pas à 100% ce qui est demandé par la FDA. Par exemple, la cybersécurité est un concept qui n’est pas du tout présent dans la norme IEC 62304, alors que la FDA exige maintenant des activités (et livrables documentaires) d’analyse et contrôle des risques reliés à la cybersécurité.
De plus, la norme IEC 62304 n’utilise pas toujours la même nomenclature que la FDA. Il y a donc un arrimage à faire entre les deux au niveau de certains termes. Par exemple, entre customer needs, design inputs, software requirements et software design specifications ou encore entre software item, software unit, function, module, et components. Un guide rédigé par l’organisation américaine permet de faire la correspondance plus facilement.
