MDCG 2019-11 rev.1 : ce que change la nouvelle version pour les logiciels médicaux et IVD

Depuis 2019, le guide MDCG 2019-11 constitue une référence pour les fabricants de logiciels médicaux (MDSW) et de logiciels de diagnostic in vitro (IVD MDSW). Mais dans la pratique, cette première version laissait des zones d’ombre : cas borderline non tranchés, manque de clarté sur la notion de module, ou encore interprétation variable de la Règle 11.

La révision 1, publiée ce 17 juin 2025, ne se contente pas de quelques ajouts cosmétiques. Elle apporte de vraies clarifications conceptuelles et opérationnelles, avec un accent fort sur la destination, la structuration modulaire des logiciels, et les liens avec d’autres réglementations (comme l’EHDS).

Cet article décrypte les changements majeurs, les implications concrètes pour les fabricants, et propose des cas pratiques pour vous aider à adapter vos produits et votre documentation.

1. Rappel : de quoi parle la MDCG 2019-11 ?

Le guide vise à encadrer deux notions fondamentales :

• La qualification : déterminer si un logiciel entre dans le champ du MDR ou de l’IVDR, et s’il peut être considéré comme un dispositif médical ou un accessoire.
• La classification : déterminer la classe de risque du logiciel selon son intended purpose (notamment via la Règle 11 du MDR).

Il traite aussi de cas spécifiques :

• logiciels qui “drive or influence” un DM,
• distinction entre MDSW et modules non médicaux,
• applications en cloud, sur mobile ou embarquées.

La destination (intended purpose) est au cœur de tout : il conditionne la qualification, la classification et le niveau d’exigence réglementaire.

2. Ce que change la révision 1 (juin 2025)

2.1 Clarifications apportées

• Portée du document étendue aux logiciels de l’Annexe XVI (produits sans finalité médicale, ex. : appareils esthétiques).
• Destination (intended purpose) : le guide insiste sur la nécessité d’une formulation claire, précise, sans ambiguïté, chaque fonctionnalité à visée médicale doit être justifiée cliniquement.
• Approche modulaire : le document introduit une vision fine des logiciels décomposables en modules. Certains peuvent être qualifiés MDSW, d’autres non. Le fabricant doit :
• définir clairement les frontières fonctionnelles,
• documenter les interactions,
• prouver que les modules non médicaux n’impactent pas la sécurité ou la performance des modules médicaux.
• Interopérabilité avec les DME / EHR : le guide intègre la nouvelle donne posée par l’EHDS (European Health Data Space). Si vous revendiquez l’interopérabilité, vous devez répondre à des exigences supplémentaires.

2.2 Nouveaux exemples

• Cas de logiciels destinés au traitement (“intended to treat”) (notamment en santé mentale, rééducation, troubles alimentaires).
• Logiciels à usage thérapeutique via réalité virtuelle ou jeux interactifs.
• Exemples où des modules non médicaux sont nécessaires au fonctionnement global, mais ne tombent pas sous le MDR/IVDR, à condition que cette distinction soit rigoureusement établie.
• Un exemple en classe I est introduit, pour un logiciel de soutien à la communication (ex. : pour patients atteints d’autisme ou paralysie cérébrale). À noter : ce type de cas reste l’exception.

2.3 Classification et Règle 11

Le texte explicite enfin les 3 sous-règles :

• 11a : logiciels fournissant de l’information pour décisions diagnostiques ou thérapeutiques.
• 11b : logiciels de monitoring physiologique.
• 11c : tous les autres.

Des tableaux croisant gravité de la situation clinique et niveau de décision médicale supportée (informer / orienter / décider) permettent de faire le lien avec le cadre IMDRF.

3. Scénarios pratiques : ce que ça change pour vous

Cas 1 – Logiciel de rééducation modulaire

Un éditeur développe une plateforme de rééducation combinant :

• un module de réalité virtuelle thérapeutique (MDSW),
• un module de suivi administratif (non MDSW),
• un module de suivi de l’assiduité du patient.

Ce que dit la révision 1 :

• Chaque module doit être évalué séparément.
• Le module thérapeutique sera classé selon la Règle 11.
• Les modules non médicaux doivent être décrits et leur interaction analysée dans le dossier technique.

Cas 2 – Logiciel connecté à un DME

Un outil d’aide à la décision thérapeutique est interfacé avec un EHR certifié.

Ce que dit la révision 1 :

• Si le fabricant revendique cette interopérabilité, il doit aussi répondre aux exigences EHDS (interopérabilité, documentation, cybersécurité).
• La qualification MDR n’est pas suffisante : le champ réglementaire devient double.

4. Questions fréquentes (mini FAQ)

1. Mon logiciel reste-t-il en classe IIa si je ne change pas l’algorithme ?

Non. Ce qui compte, c’est l’impact des décisions supportées. Même sans changement technique, votre positionnement réglementaire peut évoluer avec la révision.

2. Puis-je déclarer mes modules non médicaux comme “hors scope” ?

Oui, mais uniquement si vous justifiez qu’ils n’interfèrent pas avec les modules médicaux (performance, sécurité, etc.).

3. L’hébergement cloud change-t-il la classification ?

Non. La localisation (cloud, embarqué, mobile) ne change rien à la qualification ou à la classification. Cela dit, si votre logiciel est hébergé en ligne, certaines exigences supplémentaires peuvent s’appliquer (cybersécurité, disponibilité, traçabilité). Pour aller plus loin sur ce sujet, voir notre article sur le Nouveau guide MDCG 2025-4 : obligations pour les apps logicielles de dispositifs médicaux sur les plateformes en ligne.

4. Que faire si je veux connecter mon logiciel à un EHR ?

Vous devrez respecter les exigences EHDS et MDR/IVDR. Une documentation spécifique sur l’interopérabilité est exigée.

5. Dois-je requalifier un logiciel auparavant jugé non MDSW ?

Potentiellement oui. Des cas auparavant borderline sont désormais clairement qualifiés comme MDSW.

5. Ce que les fabricants doivent faire maintenant

• Revoir la destination (intended purpose) avec rigueur et alignement clinique.
• Cartographier l’architecture logicielle : modules, flux de données, interfaces.
• Requalifier les modules borderline à la lumière des nouveaux exemples.
• Actualiser la documentation technique : justification de la classe, analyse des interfaces, conformité EHDS si applicable.
• Réévaluer vos stratégies d’évaluation clinique/performance pour chaque module concerné.

6. Conclusion

Cette révision n’est pas un simple ajustement : c’est une consolidation du cadre d’interprétation. Elle permet enfin de trancher certains cas ambigus (traitement, modulaire, interopérabilité), tout en renforçant les exigences en matière de justification.

Elle impose un effort d’analyse aux fabricants, mais elle offre aussi une opportunité : celle de structurer vos développements et votre documentation de manière plus robuste et plus claire.

Besoin d’un accompagnement stratégique ?

Chez CSDmed, nous vous aidons à :

• Structurer votre destination (intended purpose) et vos modules,
• Classifier vos logiciels avec méthode,
• Intégrer les exigences MDR, IVDR, AIA et EHDS sans surcharger vos projets.

Vous développez un logiciel de santé ? Ne partez pas sur de mauvaises bases. Parlons-en.