MDCG 2019-11 Rev.1

De nouveaux repères pour les fabricants de logiciels médicaux

Date de publication
19/06/2025

Les éléments impactant la stratégie de classification et règlementaire

La révision 1 du guide MDCG 2019-11, publiée en juin 2025, apporte des clarifications clés pour les fabricants de logiciels médicaux (MDSW - Medical Device Software, MDSW) dans le cadre du règlement (UE) MDR 2017/745 et du règlement (UE) IVDR 2017/746.

Cette mise à jour concerne directement les fabricants de logiciels utilisés dans le secteur de la santé, et plus largement tous les acteurs développant des solutions numériques à finalité médicale.


1. L’« Intended Purpose » devient central

La finalité d’usage revendiquée (intended purpose) est la pierre angulaire de toute stratégie de qualification et de classification. La révision rappelle l’importance de décrire de façon précise, non ambiguë, chaque fonctionnalité médicale d’un logiciel.

Les logiciels purement administratifs, de gestion ou de bien-être ne sont pas considérés comme dispositifs médicaux, sauf s’ils remplissent les critères de qualification (ex. : impact sur la santé, support à la décision thérapeutique).

Les logiciels liés à des produits listés dans l’annexe XVI du MDR (ex : produits esthétiques ou bien-être avec risque pour la santé) sont également couverts, et doivent être évalués à l’aune des spécifications communes (CS) établies par la Commission.

Le guide insiste : une finalité d’utilisation vague ou mal définie peut compromettre toute la stratégie de qualification et de classification.

Recommandation :

Cartographiez finement les modules de votre logiciel et leurs interactions. Documentez les impacts fonctionnels entre composants. Cette analyse conditionne votre stratégie de développement, de test et de documentation technique.

2. Approche modulaire : documenter chaque brique fonctionnelle

La révision met fin à la simple distinction « médical / non médical » entre modules. Si une fonction non médicale interagit avec une fonctionnalité médicale, ou impacte la performance ou la sécurité, elle entre dans le champ du MDR.

Chaque module d’un logiciel peut être évalué séparément, notamment lors d’ajouts fonctionnels ou de mises à jour.

Les fabricants doivent donc documenter :

  • le rôle et l’objectif de chaque module,
  • les interactions entre modules,
  • l’impact potentiel sur la performance globale du logiciel.

Recommandation :

Formalisez votre intended purpose très tôt dans votre projet. Il doit refléter fidèlement les usages cliniques prévus, tout en étant aligné avec vos données de validation et vos promesses marketing.

3. Clarification des logiciels de l’annexe XVI

La révision apporte des précisions sur les logiciels qui relèvent de l’annexe XVI du MDR, c’est-à-dire ceux sans but médical mais qui présentent un risque pour la santé (ex : logiciels de remodelage corporel, de stimulation cérébrale non invasive, etc.).

Ces logiciels sont soumis aux mêmes exigences que les DM traditionnels : évaluation clinique, analyse de risques, documentation technique, etc.

L’application des spécifications communes est essentielle pour justifier leur conformité.

Recommandation :

Analysez systématiquement vos logiciels borderline à la lumière de l’annexe XVI et des Spécifications Communes. Une mauvaise qualification entraîne des décalages critiques en accès au marché.

4. Nouvelles illustrations de MDSW

La révision enrichit le guide d’exemples concrets, illustrant la variété des usages reconnus comme MDSW :

  • Logiciels d’aide à la thérapie (ex : logiciels de rééducation personnalisée, applications de suivi de traitement pour la schizophrénie ou la dépression).

  • Logiciels destinés à la prévention du risque de maladie (ex : applications d’alerte pour maladies chroniques, modules de suivi de l’adhésion au traitement).

  • Logiciels de diagnostic par analyse d’images, de surveillance physiologique, ou d’aide à la décision thérapeutique.

Ces cas concrets permettent de mieux comprendre les critères de qualification et la logique d’évaluation réglementaire.

Dispositifs Médicaux Logiciels, quel est le chemin vers l'accès au marché ?

5. Renforcement de la règle 11 : vers une meilleure objectivation des risques

La révision précise les modalités d’application de la règle 11 du MDR, qui concerne les logiciels utilisés pour fournir des informations déterminantes à des fins de diagnostic ou de traitement.

Trois sous-catégories de risque sont désormais mieux différenciées :

  • Classe IIa : logiciel fournissant des informations pour des décisions diagnostiques ou thérapeutiques, sans prise en compte de l’impact sur la santé.

  • Classe IIb : si une erreur peut entraîner une détérioration grave de la santé ou nécessiter une intervention chirurgicale.

  • Classe III : si une erreur peut entraîner la mort ou une détérioration irréversible de la santé.

Des exemples concrets sont fournis, notamment pour les logiciels destinés à prévenir le risque de maladie (ex : applications d’alerte pour patients à risque, modules de suivi de paramètres critiques).

Recommandation :

Développez une grille d’analyse des usages et de leurs risques cliniques associés. Une sur- ou sous-classification peut être très pénalisante dans vos démarches de certification.

6. Interopérabilité : un critère réglementaire à part entière

Le guide introduit une exigence explicite de documentation des interactions avec les systèmes tiers (DMP, EHR, logiciels hospitaliers…).

Toute revendication de compatibilité technique engage le fabricant, qui devra fournir des preuves de test, de validation, et garantir l’impact sur la sécurité et les performances.

Recommandation :

Encadrez contractuellement et techniquement vos interfaces. Documentez les versions, normes et types d’intégration. Cette traçabilité est indispensable pour votre dossier technique.

7. Nouveau : un exemple de logiciel médical en classe I

Tous les MDSW ne sont pas systématiquement en classe IIa ou plus. La révision apporte un exemple concret de logiciel en classe I, sous conditions très strictes.

Recommandation :

Explorez les opportunités de classe I uniquement si vos fonctionnalités ne relèvent pas d’une aide à la décision médicale, et si aucune fonction n’impacte directement la prise en charge ou le diagnostic.

En synthèse

Cette révision du guide MDCG 2019-11 constitue un outil de clarification important pour les fabricants de MDSW. Elle renforce l’exigence de précision, de documentation et d’objectivation des décisions de qualification et de classification.

Les prochaines étapes à réaliser si vous êtes fabricant :

  • Réviser vos intended purposes et les formaliser sans ambiguïté

  • Structurer une évaluation modulaire avec analyse d’impact fonctionnel

  • Valider vos choix de classification à l’aide d’exemples et de matrices de risque

  • Anticiper les obligations liées à l’interopérabilité

  • Mettre à jour vos dossiers techniques en cohérence avec les nouvelles attentes


Références utiles :

Notre équipe vous accompagne pour transformer ces exigences en levier de structuration et de valorisation de vos logiciels médicaux.