Les instruments médicaux ne sont plus uniquement des outils purement mécaniques limités à des fonctions physiques. Aujourd’hui, ils assistent complètement les professionnels de la santé dans l’exercice de leur métier et orientent leurs décisions médicales. L’intégration de composants électroniques, d’écrans et de logiciels, ainsi que l’arrivée de la connectivité puis de l’IA, les rendent plus précis, plus fiables, et plus faciles à utiliser. Derrière les données qu’ils collectent et qu’ils traitent, se cache un ou plusieurs logiciels.
Parmi eux, le logiciel en tant que dispositif médical (Software as a Medical Device ou SaMD) a une place particulière. Reconnu comme un dispositif médical à part entière, il est soumis à un cadre réglementaire strict établi par la FDA aux États-Unis, Santé Canada et le règlement MDR de l’Union européenne.
Son potentiel à améliorer les soins en santé n’est plus à prouver, et ce type de logiciel fait partie des tendances clé pour les prochaines années. On prévoit que le marché des SaMD devrait atteindre 93,08 milliards USD d’ici 2031 (contre 30,17 milliards USD en 2023).
Si votre objectif est de développer un logiciel en tant que dispositif médical (SaMD), cet article explore les spécificités à connaître avant de vous lancer:
- La définition d’un logiciel en tant que dispositif médical (SaMD)
- Des exemples d’utilisation de SaMD
- La classification des SaMD
- Le cadre réglementaire d’un SaMD
- 5 bonnes pratiques pour développer un SaMD
Qu’est-ce qu’un logiciel en tant que dispositif médical (SaMD)?
Le Forum international des organismes de réglementation des dispositifs médicaux (IMDRF) définit le logiciel en tant que dispositif médical (SaMD) comme un logiciel fonctionnant de manière autonome destiné à diagnostiquer, traiter ou prévenir une maladie sans dépendre d’un matériel médical spécifique.
Ainsi, un SaMD peut-être une application ou une plateforme Cloud utilisée à des fins médicales sur des smartphones, des tablettes ou des ordinateurs de bureau.
Un logiciel n’est pas non plus identifié comme un SaMD s’il ne fonctionne pas de manière autonome, c’est-à-dire, s’il est intégré à un dispositif médical. Dans ce cas, il s’agit d’un SiMD (Software in a Medical Device ou logiciel dans un dispositif médical), un logiciel dont le rôle est de contrôler les fonctionnalités ou les performances principales de l’appareil. Il est aussi appelé logiciel intégré, micrologiciel ou microcode.
| SaMD | pas SaMD |
|---|---|
| Une application mobile qui analyse les données ECG afin de détecter les arythmies et de recommander un suivi médical. | Un logiciel qui contrôle les signaux électriques d'un stimulateur cardiaque (SiMD). |
| Une plateforme basée sur l'IA qui analyse les données de santé des patients afin de proposer des options de traitement personnalisées. | Un système informatisé pour l’hôpital qui stocke les dossiers des patients ou les informations de facturation. |
| Un outil basé sur le cloud qui prévient le risque de complications liées au diabète en fonction des données saisies par le patient. | Une application de suivi de la condition physique qui mesure les pas et les calories. |
| Logiciel qui calcule les doses de radiation pour les traitements contre le cancer. | Logiciel qui administre le traitement d’un appareil de radiothérapie (SiMD). |
Exemples d’utilisation de logiciel en tant que dispositif médical (SaMD)
Le diagnostic
Le logiciel interprète les images médicales, les signaux ou les données des patients afin d’aider à prendre une décision clinique. Par exemple, il peut s’agir de détecter des tumeurs dans les examens de tomodensitométrie (CT scans), d’identifier des maladies oculaires dans les images rétiniennes, ou de détecter des rythmes cardiaques anormaux à partir d’enregistrements de cardiogrammes.
Le traitement
La surveillance
La prévention
La classification des logiciels en tant que dispositif médicaux (SaMD)
Identifier la classification d’un logiciel en tant que dispositif médical permet de connaître les exigences requises par chaque organisme réglementaire en vue d’une approbation pour la mise en marché.
La classification de la FDA pour les États-Unis
La FDA utilise un modèle de classification à trois niveaux relativement simple, mais qui impose des contrôles spéciaux supplémentaires pour les dispositifs médicaux de la classe II.
- La classe I regroupe les logiciels représentant le risque le plus faible. On y retrouve ceux qui soutiennent le bien-être général, ou ceux qui aident à poser un diagnostic simple.
- La classe II regroupe les logiciels à risque modérés comme des outils d’interprétation d’électrocardiogramme ou des calculateurs de dosage d’insuline. Afin de garantir leur fiabilité et leur efficacité, la FDA impose des contrôles spéciaux supplémentaires qui s’ajoutent aux contrôles généraux.
- La classe III regroupe les logiciels à haut risque. On y retrouve ceux qui, par exemple, permettent de maintenir des patients en vie comme c’est le cas des applications qui paramètrent les stimulateurs cardiaques.
La classification de Santé Canada
Santé Canada étend sa classification à quatre classes, apportant ainsi une couche supplémentaire pour catégoriser les logiciels à risques élevés et ceux à risque très élevés.
- La classe I rassemble les logiciels dont le risque est le plus faible. Ils sont généralement exemptés de licence.
- La classe II regroupe les logiciels à risque modéré tels que les visionneuses d’images capables de prendre des mesures.
- La classe III rassemble les logiciels à risque élevé. C’est le cas de ceux qui jouent un rôle dans la prise de décisions thérapeutiques critiques.
- La classe IV est réservée aux logiciels à risque très élevé. On y retrouve les outils utilisés dans le traitement du cancer, dont le mauvais fonctionnement pourrait avoir des conséquences mortelles.
La classification de l’Union européenne
La réglementation de l’Union européenne (EU MDR) applique la règle 11 qui évalue les risques en se basant sur leur contexte et la gravité de leurs conséquences, en se concentrant en particulier sur la pose de diagnostic ou la prise de décisions thérapeutiques.
- La classe IIa regroupe les logiciels fournissant des informations à des fins diagnostiques ou thérapeutiques.
- La classe IIb regroupe les logiciels susceptibles d’entraîner une détérioration grave de la santé en cas d’une mauvaise décision.
- La classe III concerne les logiciels pouvant entraîner la mort ou avoir des conséquences irréversibles sur la santé.
Le cadre réglementaire d’un logiciel en tant que dispositif médical (SaMD)
Les SaMD sont soumis à des normes qui garantissent leur qualité, leur sécurité et leur conformité. L’ensemble de ces normes fournit un cadre réglementaire commun pour garantir la fiabilité des logiciels utilisés dans les environnements cliniques.
IEC 62304
IEC 62304 est une norme incontournable pour la gestion du cycle de vie des logiciels de dispositifs médicaux. Elle définit les exigences relatives, notamment, au développement, à la maintenance, et au contrôle des risques.
Elle identifie les logiciels selon trois classes de sécurité. Pour cela, elle se base sur le niveau de gravité du dommage potentiel que pourrait causer une défaillance. Plus le niveau est élevé, plus le nombre d’activités exigées par la norme est important. Cette classification permet donc de déterminer le volume de documentation, de tests et d’activités de vérification nécessaire.
| Classe | Niveau de gravité du dommage potentiel |
|---|---|
| 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. |
IEC 82304
La norme IEC 82304 cible les logiciels de santé qui fonctionnent de manière autonome, tels que les applications mobiles de santé ou les plateformes de diagnostic hébergées sur le Cloud. Elle donne donc des recommandations essentielles qui concernent directement les développeurs de SaMD.
Contrairement à la norme IEC 62304 qui se concentre sur le processus interne de développement logiciel, IEC 82304 s’intéresse au produit logiciel dans sa globalité: l’étiquetage, les instructions d’utilisation, la cybersécurité, et la performance du logiciel tout au long de son cycle de vie. Son objectif est de s’assurer que le logiciel est sécuritaire, fiable et facile à utiliser.
ISO 13485
La norme ISO 13485 est une norme internationale pour les systèmes de gestion de la qualité (SGQ) spécifique aux dispositifs médicaux. Pour les développeurs de SaMD, l’application de cette norme signifie que les processus sont intégrés dans un cadre organisationnel plus large qui implique le contrôle des documents, des revues de conception, et des actions correctives.
Une entreprise qui est certifiée ISO 13485 (comme nous!) démontre ainsi que ses pratiques sont cohérentes et apparaît plus fiable aux yeux des instances réglementaires et des clients.
ISO 14971
La norme ISO 14971 est une référence mondiale pour la gestion des risques liés aux dispositifs médicaux, y compris les SaMD. Elle exige notamment d’identifier les dangers liés à l’utilisation des logiciels (par exemple, les erreurs d’algorithmes, les failles de cybersécurité, les interprétations erronées des données), d’évaluer leur gravité et leur probabilité. Si des risques sont identifiés, des mesures doivent être prises pour les atténuer.
| Norme | Périmètre d'application | Impact sur le SaMD |
|---|---|---|
| IEC 62304 | Cycle de vie du logiciel | Définit les exigences pour le développement, les tests et la maintenance. |
| IEC 82304 | Logiciel de santé autonome | Garantit la sécurité, la fiabilité, la facilité d’utilisation et la cybersécurité du logiciel. |
| ISO 13485 | Système de gestion de la qualité | Intègre le logiciel dans les processus propres au système de gestion de la qualité de l’entreprise. |
| ISO 14971 | Gestion des risques | Identifie, évalue et atténue les risques liés à l’utilisation du logiciel. |
5 bonnes pratiques pour développer un logiciel en tant que dispositif médical (SaMD)
Le développement de SaMD obéit aux mêmes principes que celui des autres types de logiciels. Cependant, pour le mener à bien, il est nécessaire de suivre un processus structuré qui prend en considération les normes évoquées précédemment.
