L’Europe veut tuer les logiciels médicaux, la France bonne élève

Je n’aime pas surfer sur la vague de “la règlementation qui vient égorger nos fils et nos DM”, mais pour les logiciels cela devient du délire.

Cet article explique comment, par peur d’un sujet qu’elle comprend mal, la règlementation fait du logiciel un cas particulier mal mené, quitte à décourager des projets utiles de softs médicaux.

Sur le chemin de la route

Un point d’histoire : la réglementation européenne sur les DM s’est intéressée aux logiciels en 2007, lorsque les softs sont entrés au forceps dans la directive 93/42/CEE. Un dispositif médical pouvait déjà concerner “tout instrument, appareil, … ou autre article” mais l’année de 2007 était au numérique (nous sommes en l’an 0 après le iPhone) un “y compris le logiciel” a ainsi été ajouté à la définition de DM. Et ce n’est malheureusement pas la seule particularité règlementaire pour les softs.

Il est rare qu’une règlementation “générale” précise des points purement techniques, le RDM le fait pour les logiciels et les nanomatériaux, avec une approche à la truelle des règles de classification.

À risques égaux, classes différentes

Le règlement 2017/745 est livré de série avec la règle 11, spécialement pensée pour les logiciels :

Les logiciels destinés à fournir des informations utilisées pour prendre des décisions à des fins thérapeutiques ou diagnostiques sont de classe :

• III si susceptible de causer la mort ou une détérioration irréversible
• IIb si susceptible de causer une grave détérioration / une intervention chirurgicale
• ⚡IIa sinon⚡

Les logiciels destinés à contrôler des processus physiologiques sont de classe :

• IIb si mesure de signaux vitaux + danger immédiat
• IIa si mesure de signaux vitaux sans danger immédiat pour l vie du patient

Les autres logiciels sont en classe I.

Première remarque : vous pouvez risquer la mort d’un patient, en cas de contrôle cela vous en coutera une classe IIb, ce sera classe III pour du thérapeutique ou du diagnostic.

Seconde remarque sur les logiciels pour prise de décision : où est la classe I ?

Sus aux softs sans risque

Attendu fébrilement, un guide du MDCG va préciser les règles de classification du RDM pour les softs, d’ici quelques semaines, mois ou trimestres.

L’occasion de remettre l’approche par les risques au cœur du débat de s’enfoncer dans la phobie du logiciel :

• la première partie de la règle 11 serait applicable à tous les DM logiciels (dont les autres et ceux pour le contrôle)
• bien que basée sur les règles proposées par l’IMDRF, la classe I a délibérément été écartée, parce que nous le valons bien.

Ci-dessous un comparatif Europe / IMDRF :

Le journal du hard

Une piste de sortie pour les logiciels embarqués vise à exploiter une des règles d’application :

“Le logiciel commandant un dispositif ou agissant sur son utilisation relève de la même classe que le dispositif.“

Cette règle, discutée dans le guide MDCG, ♪ pourrait ♬ amener à ♪ conclure ♫ qu’un logiciel embarqué qui se contente de piloter les I/O d’un DM électromédical, ou de communiquer des infos sans traitement médical (type algo de diagnostic ou de choix thérapeutique) n’est pas soumis à la première partie de la règle 11.

Restent alors les règles 9 et 10 et, à moins de piloter un DMIA, vous couperez à la classe III. Les cas les plus dangereux, dont les cas mortels, sont cantonnés à la classe IIb 😵.

Mais le problème semble toujours entier pour les logiciels autonomes… Bonne nouvelle : le pascaline (#frenchTech qui plus est) devrait résoudre vos problèmes de règle 11 💪.

HAS : Halte Aux Softs

En France, on n’a pas de culture numérique, mais on a des idées sur le sujet.

La HAS a publié ses relents perspectives en matière de numérique, les logiciels (remboursés) y sont littéralement massacrés.

Extraits commentés :

Tout le monde s’accorde à dire que les logiciels destinés à fournir aux professionnels des informations utilisées pour prendre des décisions à des fins thérapeutiques ou diagnostiques, présentent des niveaux de risque variables.
En effet, à produits différents risques différents

Il est donc urgent
La causalité est surprenante

que les professionnels puissent s’assurer de la qualité clinique des décisions suggérées par les logiciels, surtout pour celles qui sont le plus à risque pour leurs patients.
cf. CE.

Les pouvoirs publics doivent se donner les moyens de leur fournir des repères pour les aider à faire ces choix
Il semble que ce soit le rôle des ON, qui ont la chance d’avoir moyens et compétences

Ceux les plus à risque, dont les fonctionnalités sont susceptibles de causer la mort ou une détérioration grave ou irréversible de l’état de santé d’une personne, devraient faire l’objet d’une évaluation robuste ex ante, complémentaire à celle du marquage CE.
Une telle initiative aurait été justifiée sous la directive, assez laxiste avec le logiciel, mais avec le règlement il n’est pas nécessaire de s’acharner sur le cadavre.

Les logiciels les plus dangereux ont déjà droit à classe III, évaluation clinique, investigation clinique, suivi clinique et, un jour, experts européens pour l’évaluation des évaluations des évaluations cliniques (oui, il y en a trois). Et c’est sans parler de l’IEC 62304, une particularité pour logiciel imposant un quasi-SMQ en plus de l’ISO 13485. De rien.

Conclusion

Trois options si vous souffrez de règle 11 :

1. Revoir les ambitions du soft
2. Abandonner le soft
3. Traverser l’atlantique