.svg){kind=small}
Différentes normes régissent la construction de dispositif médicaux, et le développement des logiciels associés. S’il est possible que l’on demande un jour à Chat GPT si une application de santé est 100% sécurisée, des normes réglementaires ont été définies pour protéger le patient et garantir sa santé. Faisons le tour d’horizon des différentes normes et comment cela s’applique aux développements des dispositifs médicaux digitaux.
Classe 1 (I), 2 (II), 3 (III), classe A,B,C, l’ambiguïté peut être rapide lorsque l’on évoque les classifications des dispositifs médicaux.
Chez Hokla, notre spécialité, c’est la réalisation de ⭐️ dispositifs médicaux numériques ⭐️.
Dans cet article, nous allons voir pourquoi les chiffres et les lettres ne sont pas qu’une émission de télévision, et l’importance de bien connaître la distinction pour pouvoir faire certifier une application dispositif médicale sans encombre et rapidement.
La définition officielle d’un dispositif médical est:
“tout “instrument, appareil, équipement, logiciel, matière ou autre article, utilisé seul ou en association, destiné par le fabricant à être utilisé chez l’homme pour :
et dont l’action principale voulue dans (ou sur) le corps humain n’est pas obtenue par des moyens pharmacologiques, immunologiques ou métaboliques, mais dont la fonction peut être assistée par de tels moyens.”
Pour être commercialisé en Europe, les dispositifs médicaux sont soumis à l’obligation d’avoir un marquage CE, et donc respecter des normes européennes concernant les dispositifs médicaux.
C’est avec ce cadre réglementaire que sont introduites les classifications règlementaires des dispositifs médicaux.
.png)
La norme introduit 4 niveaux de classifications, de I à III, avec une classe IIa et IIb.
La classification se fait selon le risque inhérent à l’usage du dispositif pour la santé du patient, et du fait qu’il soit invasif ou non.
La classification a un impact direct sur les exigences à remplir pour obtenir le marquage CE.
En effet, les dispositifs médicaux de classe I sont auto-certifiés. Cela signifie qu’une entreprise peut acquérir un marquage CE sans passer par un organisme externe (et seulement par les personnes responsables au sein de leur entreprise), réduisant fortement le temps pour se faire certifier.
Un SaMD (software as medical device) peut être de deux différents composites
La distinction entre les deux cas est importante.
En effet, si nous créons un logiciel dispositif médical à part entière, alors il est nécessaire de définir sa classe réglementaire. Cependant, si nous créons un logiciel nécessaire au bon fonctionnement d’un dispositif médical, alors le logiciel hérite de la classe réglementaire du dispositif médical, et la documentation à fournir est moindre (on précise uniquement que le logiciel prend la classe réglementaire de son dispositif associé).
Exemple: une application mobile de gestion d’une pompe à insuline sera de classe réglementaire III, héritant de la classe III de la pompe à insuline.
Classes de sécurité d’un SaMD
Si les classes réglementaires régissent l’usage du dispositif médical, la création d’un dispositif numérique est régie par une norme différente liée à directement au développement du logiciel. Il s’agit de la norme 62304.
Ainsi, une entreprise comme Hokla doit fournir des documents relatifs à la conception des logiciels qu’elle conçoit. Ces documents dépendant de la criticité du logiciel, aussi appelée classe de sécurité.
Ces classes, définies uniquement pour les logiciels, sont nommées A, B et C, allant de l’ordre croissant du risque sur la santé du patient, de risque minime (classe de sécurité A) au risque de mort (classe de sécurité C).
Ainsi, pour résumer, un logiciel dispositif médical à part entière est donc classé en tant que dispositif médical et en tant que logiciel conçu en suivant la norme.
C’est donc pour cela que l’on peut entendre le mot “classe” sans distinction du type de classification.
Exemple: une application de calcul de respiration cardiaque peut être de classe (réglementaire) IIa, et de classe (de sécurité) B.
La documentation justifiant les choix de classe de sécurité prenant du temps à écrire, nous pouvons nous poser la question de pourquoi vouloir classifier absolument les logiciels dispositifs médicaux, et ne pas juste considérer tous les SaMD comme tous de classe C.
Réponse: Les documentations à fournir dans le cadre de la certification d’un SaMD sont d’autant plus importantes en nombre que la classe de sécurité est élevée.
.png)
Ainsi, si vous avez la possibilité de justifier un SaMD comme une classe de sécurité A, alors vous réduirez fortement le nombre de documentations à fournir pour certifier le logiciel, et votre capacité à mettre sur le marché celui-ci sera optimale.
Nous avons vu que les logiciels dispositifs médicaux peuvent aussi être considérés comme des dispositifs médicaux à part entière, entretenant de fait une ambiguïté entre sa classe réglementaire en tant que dispositif médical, et sa classe de sécurité en tant que SaMD.
Néanmoins, les normes actuelles ont été définies il y a maintenant plusieurs années, et le monde du logiciel et des SaMD a fortement évolué pendant ce temps. Le marché pousse pour changer les normes pour introduire des phases de documentations plus cohérentes avec les méthodologies mordernes de développement (Agile notamment).
Il ne serait donc pas étonnant que les normes évoluent aussi dans les prochains mois.
I'm a passionate software craftman who loves working for companies i truly believe change the world. Hokla is one of them. Hit me up on Twitter @xav_marchal or xavierm [at] hokla.com
.svg)
.svg)
