Exigences du règlement DM pour les logiciels médicaux
Liste des exigences du règlement UE relatif aux dispositifs médicaux qui sont propres aux logiciels.
Un logiciel peut être un dispositif médical
Définition de Dispositif Médical
Le règlement définit la notion de dispositif médical dans l’article 2.1:
Dispositif médical : tout instrument, appareil, équipement, logiciel, implant, réactif, matière 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édiction, pronostic, traitement ou atténuation d’une maladie,
– diagnostic, contrôle, traitement, atténuation d’une blessure ou d’un handicap ou compensation de ceux-ci,
– investigation, 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.
- Ils 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 en introduction :
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 (ce n’est pas vrai si vous codez des macros à finalité médicale).
- 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, la France aussi.
- Contourner la réglementation via des revendications volontairement à la baisse. Mais je vois le mal partout.
Les logiciels médicaux sont-ils 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 réputés être des dispositifs actifs.
Rq : Le “réputés” pourrait être ambigu, mais les softs sont bien des DM actifs : il y a des règles de classification pour DM actif dédiées au logiciel.
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 logiciels :
14.2 (d) (é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.
Le point 17 des exigences essentielles est dédié aux logiciels :
17.1. Les dispositifs comportant des systèmes électroniques programmables, notamment des logiciels, ou les logiciels qui sont des dispositifs à part entière 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.
17.2. Pour les dispositifs qui comprennent des logiciels ou pour les logiciels qui sont des dispositifs à part entière, ces logiciels sont développés et fabriqués conformément à l’état de l’art, 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.
17.3. Les logiciels visés à la présente section qui sont 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 (par exemple, taille et rapport de contraste de l’écran) et des facteurs externes liés à leur utilisation (variation du niveau sonore ou de la luminosité dans l’environnement).
17.4. Les fabricants énoncent les exigences 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 de l’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 VIII (voir l’article sur la classification des DM dans le règlement).
La tendance est au durcissement pour les logiciels :
Règles d’applications : 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.
règle 11: 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 ces décisions ont une incidence susceptible de causer:
– la mort ou une détérioration irréversible de l’état de santé d’une personne, auxquels cas ils relèvent de la classe III, ou
– une grave détérioration de l’état de santé d’une personne 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 1ᵉʳ : 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).
Certification des logiciels médicaux
Le règlement demande de générer une documentation conséquente autour du logiciel :
6.1 : 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 libération 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 sera ici d’un grand renfort.
Logiciel et IUD
On en parle depuis des années, l’UDI (Unique Device Identifier) arrive, c’est d’ailleurs une des nouveautés de la 13485:2016, cela ne concerne ici que les softs autonomes :
Annexe VI, Partie C, 6.5.1 : L’IUD est attribué au niveau du système du logiciel. Seul les logiciels qui sont disponibles en soi dans le commerce et ceux qui constituent un dispositif à part entière sont soumis à cette exigence.
Marquage et informations fournies à l’utilisateur
Des éléments sont à préciser :
- comment choisir un logiciel adapté
- exigences sur le matériel informatique à utiliser
- exigences sur les caractéristiques du réseau informatique où sera connecté le soft
- mesure de sécurité informatique à prendre
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.
39 commentaires