MDCG 2019-11 : qualification et la classification des logiciels selon le règlement dispositifs médicaux

Le guide MDCG 2019-11, traite de la qualification de dispositif médical et de la classification des logiciels dans le cadre du règlement (UE) 2017/745.

Ces logiciels peuvent être utilisés seuls ou en combinaison avec un DM.

Le contenu du guide est résumé ci-dessous.

Nouvelles définitions

Les termes suivants sont définis pour les besoins du guide, elles sont regroupées dans le dictionnaire du DM :

• Logiciel
• Donnée d’entrée d’un logiciel
• Donnée de sortie d’un logiciel
• Logiciel commandant un dispositif ou agissant sur son utilisation
• Logiciel Dispositif Médical

Qualification des logiciels dispositifs médicaux

Principes

• Un logiciel ayant une finalité médicale est un DM.
• Les logiciels accessoires de DM sont considérés comme des DM.
• Un logiciel commandant un dispositif ou agissant sur son utilisation est considéré comme un DM

Un logiciel DM peut :

• contrôler directement un DM matériel (p. ex. un logiciel de traitement de radiothérapie),
• fournir des informations utilisées dans le cadre d’une prise de décision (p. ex. un logiciel de glucomètre);
• fournir un soutien aux professionnels de la santé (p. ex. un logiciel d’interprétation ECG).

Un logiciel destiné à traiter, analyser, créer ou modifier des renseignements médicaux peut être qualifié de logiciel DM si la création ou la modification de ces renseignements est régie par une finalité médicale (selon la définition de DM).

Logigramme pour évaluer si un logiciel est soumis au règlement 2017/745

Le guide MDCG 2019-11 propose le logigramme ci-dessous pour évaluer le statut médical d’un logiciel :

Logiciel médical ou non-médical ?

• Systèmes d’information hospitaliers : non DM
• Logiciel d‘aide à la décision : DM
• Dossiers patients électroniques : non DM*
• Systèmes d’information clinique – / Systèmes de gestion des données patient : non DM*
• Système de gestion des ECG en pré-hospitalier (télétransmission) : non DM*
• PACS : DM si ne se contente pas de stocker ou d’afficher les images
• Système de communication (mail, mobile, vidéo…) pour transfert d’informations : non DM*
• Système pour télé-chirurgie : DM
• Interface web pour la surveillance de données cliniques : DM sauf pour les modules purement administratifs
• Logiciel de calcul de score de risque : DM

* : attention au statut des modules

Classification des logiciels DM

Règles d’application pour les logiciels ayant plusieurs finalités

En écho aux règles d’application 3.3 et 3.5 (annexe XVIII.2) :

3.3. Le logiciel commandant un dispositif ou agissant sur son utilisation relève 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.

3.5. Si plusieurs règles ou, dans le cadre d’une même règle, plusieurs sous-règles s’appliquent au même dispositif du fait de la destination de celui-ci, la règle ou la sous-règle qui s’applique est la plus stricte, le dispositif étant classé dans la classe la plus élevée.

Un logiciel indépendant pour certaines utilisations et pilotant ou agissant sur un DM dans d’autres utilisations sera classé selon la classe la plus élevée : celle du logiciel indépendant ou celle du dispositif hardware.

Règles applicables aux logiciels (autres que la règle 11)

De nombreuses règles de classification sont applicables aux logiciels (voir annexe VIII.III), elles prendront le dessus ci – par miracle – la règle 11 ne donne pas une classe plus élevée.

Rappel des règles :

• Règle 9 : dispositifs actifs thérapeutiques destinés à fournir ou à transférer de l’énergie, dispositifs actifs destinés à commander ou à contrôler ou à agir directement sur les performances des dispositifs actifs thérapeutiques de classe IIb, dispositifs actifs destinés à émettre des rayonnements ionisants à usage thérapeutique, dispositifs actifs destinés à commander, à contrôler ou à agir directement sur les performances des DMIA
• Règle 10 : dispositifs actifs destinés au diagnostic et au contrôle, dispositifs actifs destinés à émettre des rayonnements ionisants et destinés au radiodiagnostic ou à la radiothérapie
• Règle 12 : dispositifs actifs destinés à administrer dans l’organisme et/ou à retirer de l’organisme des médicaments, des liquides corporels ou d’autres substances
• Règle 15 : dispositifs utilisés pour la contraception ou pour prévenir la transmission de MST

En effet, les dispositifs répondant à ces finalités sont susceptibles d’embarquer du logiciel ou d’être interfacé (ou se limiter à) un logiciel autonome.

Règle de classification n°11

Pour rappel, cette règle fait tomber la quasi-totalité des logiciels en classe IIa ou supérieure :

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 guide commence fort :

Par conséquent, cette sous-règle s’applique généralement à tous les logiciels DM.

Le choix de faire tomber les logiciels en classe IIa ou supérieur est justifié en évoquant l’IMDRF, comme discuté dans cet article, c’est absurde, voir ce comparatif IMDRF/Europe (les classes Européennes y sont reportées en couleur) :

Exemples

• Logiciels destinés à établir un diagnostic au moyen de l’analyse d’images pour la prise de décisions thérapeutiques chez les patients victimes d’un AVC : classe III, règle 11(a).
• Thérapie cognitive logicielle qui comprend une fonction de diagnostic qui est destinée à être transmise au logiciel pour déterminer la thérapie de suivi : classe III, règle 22.
• Lorsqu’un spécialiste détermine la thérapie cognitive nécessaire en fonction des résultats fournis par le logiciel : classe IIa, règle 11(a).
• Logiciels destinés à être utilisés pour la surveillance continue des processus physiologiques vitaux en anesthésie, en soins intensifs ou en soins d’urgence : classe IIb, règle 11(b).
• Logiciels destinés à surveiller les processus physiologiques qui ne sont pas considérés comme vitaux ou destinés à être utilisés pour obtenir des lectures de signaux physiologiques vitaux lors des examens de routine, y compris la surveillance à domicile : IIa, règle 11(b).
• Application mobile destinée à analyser les battements cardiaques d’un utilisateur, à détecter des anomalies et à informer un médecin en conséquence (si les informations fournies par le logiciel sont destinées à guider le médecin dans son diagnostic) : classe IIb, règle 11(a), .
• Logiciel de diagnostic destiné à évaluer la dépression en fonction des données entrées sur les symptômes d’un patient (p. ex. humeur, anxiété): classe IIb, règle 11(a).
• Les systèmes de ventilation respiratoire ambulatoire logiciels destinés à un usage à long terme (p. ex. à la maison) qui alertent l’utilisateur/opérateur de toute déconnexion ou déviation du volume respiratoire programmé : classe IIb, règle 9.
• Les dispositifs actifs, tels que les thermomètres électroniques et les stéthoscopes, qui embarquent un logiciel destiné au diagnostic direct : classe IIa, selon la règle 10, troisième tiret,
• Logiciels ayant pour finalité de classer les suggestions thérapeutiques à l’intention d’un professionnel de la santé en fonction de critères relatifs aux antécédents du patient, par exemple, aux résultats des examens d’imagerie et aux caractéristiques du patient, pour les personnes victimes de cancer du sein héréditaire BRCA : classe IIa, règle 11.a)
• Logiciel ayant pour but d’aider la conception en calculant l’état de fertilité de l’utilisateur sur la base d’un algorithme statistique validé. L’utilisatrice saisit des données sur la santé, y compris la température corporelle de base et les jours de menstruation, pour suivre et prédire l’ovulation. L’état de fertilité de la journée en cours est reflété par l’un des trois voyants lumineux : rouge (fertile), vert (infertile) ou jaune (phase d’apprentissage / fluctuation du cycle) : classe I, règle 11c.

Mise sur le marché des logiciels dispositifs médicaux

Le guide donne des exemples de logiciels pouvant être mis sur le marché de manière autonome ou en combinaison avec un dispositif matériel.

Modules logiciels

Des modules / plug-in / extensions / add-on… peuvent être proposés pour des logiciels médicaux (ex : pont avec une interface administrative), les modules sans finalités médicales ne sont pas soumis au règlement.

Source : europa.eu