Logiciels médicaux et nouveau règlement sur les DM

reglement-europe-logiciel-medicalLe nouveau règlement sur les DM n’est pas encore sorti mais un texte (probablement) définitif est trouvable sur l’internet, ici par exemple (en Français).

Cet article fait une synthèse des exigences du règlement propres aux logiciels, de plus en plus proposés comme solutions médicales (diagnostic, suivi, mesures,…).

 

Un logiciel peut avoir le statut de dispositif médical

La définition de Dispositif Médical inclut clairement les logiciels

Le règlement définit la notion de dispositif médical dans l’article 2:

« Dispositif médical:tout instrument, appareil, équipement, logiciel, implant, réactif ou
autre article, destiné par le fabricant à être utilisé, seul ou en association, chez l’homme
pour l’une ou plusieurs des fins médicales précises suivantes :

– diagnostic, prévention, contrôle, prévision, pronostic, traitement ou atténuation d’une maladie,
– diagnostic, contrôle, traitement, atténuation ou compensation d’une blessure ou d’un handicap,
– étude, remplacement ou modification d’une structure ou fonction anatomique ou d’un processus ou état physiologique ou pathologique,
– communication d’informations au moyen d’un examen in vitro d’échantillons provenant du corps humain, y compris les dons d’organes, de sang et de tissus,

et dont l’action principale voulue dans ou sur le corps humain n’est pas obtenue par des moyens pharmacologiques ou immunologiques ni par métabolisme, mais dont la fonction peut être assistée par de tels moyens. »

On notera que:

  • Les logiciels sont bien visés.
  • Il peuvent fonctionner seul (ex: appli mobile de diagnostic) ou en association avec un DM (ex: logiciel exploitant les mesures d’un capteur).
  • C’est toujours la finalité qui caractérise l’aspect médical.

Et les applis de santé / bien-être ?

Le règlement l’évoque:

« Les logiciels destinés à des usages généraux, même lorsqu’ils sont utilisés dans un environnement de soins, ou les logiciels destinés à des usages ayant trait au mode de vie ou au bien-être, ne constituent pas des dispositifs médicaux. »

Ainsi:

  • En accord avec la définition ce n’est pas l’environnent d’utilisation qui induit un statut de DM.
  • La notion de logiciel d’usage général permet d’écarter des outils comme Excel.
  • La notion de style de vie / bien être permet de:
    • Faire des apps pour le sport, le quantified self, la qualité du sommeil,… sans tomber dans le DM. Notez que l’Europe réfléchit en parallèle à encadrer ces applis.
    • Contourner la réglementation via des revendications volontairement à la baisse. Mais je vois le mal partout.

Les logiciels sont t-ils toujours des DM actifs ?

Oui, le doute planait depuis la précédente version du texte mais une ligne a été ajoutée dans la définition de DM actif:

« Les logiciels sont considérés comme des dispositifs actifs. »

Comme avec la 93/42/CEE des règles pour déterminer la classe du dispositif sont propres aux DM actifs.

Exigences de performance et de sécurité propres aux logiciels

L’annexe I définit les exigences générales pour les DM, certaines visent spécifiquement les softs:

« 11.2 (e) (éliminer ou à réduire autant que possible) tout risque associé à une éventuelle interaction négative entre les logiciels et l’environnement informatique dans lequel ceux-ci fonctionnent et avec lequel ils interagissent. »

Exemple: les logiciels reliés à un système de PACS.

« 14.1. les logiciels (…) sont conçus de manière à garantir la répétabilité, la fiabilité et les performances eu égard à leur utilisation prévue. En condition de premier défaut, des moyens adéquats sont adoptés pour éliminer ou réduire autant que possible les risques qui en résultent ou la dégradation des performances.
14.2.(…) les logiciels sont développés et fabriqués conformément à l’état de la technique compte tenu des principes du cycle de développement, de gestion des risques, y compris la sécurité de l’information, de vérification et de validation.
14.3.Les logiciel (..) destinés à être utilisés en combinaison avec des plateformes informatiques mobiles sont conçus et fabriqués en tenant compte des caractéristiques spécifiques de la plateforme mobile (taille et rapport de contraste de l’écran, par exemple) et des facteurs externes liés à leur utilisation (variation du niveau sonore ou de la luminosité dans l’environnement).
14.3 bis. Le fabricant décrit les prescriptions minimales concernant le matériel informatique, les caractéristiques des réseaux informatiques et les mesures de sécurité informatique, y compris la protection contre l’accès non autorisé, qui sont nécessaires pour faire fonctionner le logiciel comme prévu. »

Le règlement a clairement précisé les exigences sur les logiciels, autant d’éléments non présents dans une directive 93/42/CEE consolidée pour la dernière fois en 2007 (l’année de sortie du iPhone, ça parait loin).

Règles de classification pour les logiciels

il existe toujours 4 classes: I, IIa, IIb et III en allant vers la plus critique, les règles de classification sont en annexe VII (voir l’article sur la classification des DM dans le règlement).

La tendance est au durcissement pour les logiciels:

« 3. Le logiciel commandant un dispositif ou agissant sur son utilisation relève automatiquement de la même classe que le dispositif.
Si le logiciel est indépendant de tout autre dispositif, il est classé en tant que tel. »

Les logiciels simples « répéteurs » (qui se contentent d’afficher une information fournie par un DM) ne sont pas visés.

« 5.2 bis. règle 10 bis:  Les logiciels destinés à fournir des informations utilisées pour prendre des décisions à des fins thérapeutiques ou diagnostiques relèvent de la classe IIa, sauf si les décisions ont une incidence susceptible de causer, directement ou indirectement:
– la mort ou une grave détérioration de l’état de santé, auxquels cas ils relèvent de la classe III;
– une grave détérioration de l’état de santé ou une intervention chirurgicale, auxquels cas ils relèvent de la classe IIb.

Les logiciels destinés à contrôler des processus physiologiques relèvent de la classe IIa, sauf s’ils sont destinés à contrôler des paramètres physiologiques vitaux, lorsque des variations de certains de ces paramètres peuvent présenter un danger immédiat pour la vie du patient, auxquels cas ils relèvent de la classe IIb.

Tous les autres logiciels relèvent de la classe I. »

Le second paragraphe était déjà couvert par la 93/42 (règle 10 pour les DM actifs destinés au diagnostic), la nouveauté est dans le 1ier: les logiciels d’aide à la décision sont classés de manière beaucoup plus sévère qu’avant (le cas était mal prévu, les apps était souvent en classe I) avec des classes allant de IIa jusqu’à III (!) , cela pourrait impacter des applis calculant des scores médicaux, d’aide à l’observance médicamenteuse, de gestion d’une maladie chronique, …

Les fabricants vont donc appliquer des procédures de marquage CE plus contraignantes, avec une obligation plus fréquente de gérer un système de management de la qualité (coucou ISO 13485).

Évaluation des logiciels médicaux

Le règlement demande de générer une documentation conséquente autour du logiciel:

« 6.1 (b) des informations détaillées (…) concernant en particulier : (…) la vérification et la validation du logiciel: description de la conception et du processus de développement du logiciel et preuve de la validation de celui-ci, tel qu’il est utilisé dans le dispositif fini. Ces informations incluent en règle générale un résumé des résultats de l’ensemble de la vérification, de la validation et des essais réalisés en interne et dans un environnement d’utilisation simulé ou réel avant la mise en circulation finale. En outre, elles prennent en compte toutes les différentes configurations du matériel informatique et, le cas échéant, des différents systèmes d’exploitation figurant dans les informations fournies par le fabricant;. »

Rien de bien nouveau par rapport aux bonnes pratiques, la norme EN 62304 vous serra ici d’un grand renfort.

Logiciel et identifiant unique

On en parle depuis des années, l’UDI (Unique Device Identifiant) arrive, c’est d’ailleurs une des nouveautés de la 13485:2016,  cela ne concerne ici que les softs autonomes:

« Annexe V, Partie C, 6.5., L’IUD est attribué au niveau du système logiciel. Seul les logiciels qui sont disponibles en tant que tel dans le commerce et ceux qui sont des dispositifs médicaux à part entière sont soumis à cette prescription. »

Conclusion

Même si la porte reste ouverte pour les applis « bien être », les logiciels médicaux sont plus encadrés, une tendance logique à l’heure où offre et demande explosent (*) et où l’ancienne directive trouvait ses limites.

Un coup dur pour les start-ups du DM logiciel qui vont devoir sérieusement se pencher sur la réglementation et les normes applicables.

Une bonne chose pour la qualité des logiciels utilisés par les professionnels de santé et les patients.


(*) un indicateur parmi d’autres: volume de recherche de « medical app » sur Google depuis 2007: