NELSE — Rules into realityNELSE — Rules into reality
Toutes les ressources

MDR · RÈGLE 11 · LOGICIEL MÉDICAL

MDR Rule 11 : classer un logiciel médical à partir de sa finalité réelle.

Pour un logiciel médical, la classification ne se déduit pas du fait qu’il « utilise de l’IA » ou qu’il traite des données de santé. Le raisonnement part de la finalité prévue du logiciel, de la fonction qu’il remplit et de l’impact des décisions ou du suivi qu’il permet.

9 min · mis à jour 1 octobre 2026

01

La règle 11 vise notamment les logiciels qui fournissent des informations utilisées pour des décisions diagnostiques ou thérapeutiques.

L’annexe VIII du règlement (UE) 2017/745 prévoit, dans sa règle 11, que les logiciels destinés à fournir des informations utilisées pour prendre des décisions à des fins diagnostiques ou thérapeutiques sont classés en classe IIa, avec une montée en classe lorsque l’impact potentiel de ces décisions atteint les niveaux prévus par la règle.

La règle traite également des logiciels destinés à surveiller des processus physiologiques, avec une distinction particulière pour certains paramètres physiologiques vitaux lorsque leurs variations pourraient entraîner un danger immédiat pour le patient.

02

La finalité prévue est le point de départ du dossier.

Le guide MDCG 2019-11 rev.1, révisé en juin 2025, détaille la qualification et la classification des logiciels au titre du MDR et de l’IVDR. Il insiste notamment sur l’importance de formuler clairement la finalité prévue et apporte des précisions supplémentaires sur l’application de la règle 11.

Ce guide est un document MDCG : il oriente l’application pratique mais n’est pas juridiquement contraignant et ne remplace pas l’interprétation des textes par les autorités ou les juridictions compétentes.

03

La classification doit rester reliée au produit qui existe réellement.

Une classification n’est utile que si l’on peut retrouver les faits qui l’ont produite : finalité prévue, utilisateurs, fonctions, informations produites, décisions influencées, conséquences possibles et dépendances du logiciel.

Quand une fonctionnalité change, l’organisation doit pouvoir identifier les faits modifiés et les parties du raisonnement réglementaire qui doivent être réexaminées au lieu de repartir d’un document vierge.

  • Décrire la finalité prévue et les utilisateurs ciblés.
  • Qualifier les fonctions logicielles au regard du champ MDR/IVDR.
  • Identifier la ou les règles de classification à examiner.
  • Documenter les faits qui justifient la classe retenue.
  • Attribuer les revues et validations réglementaires.
  • Réexaminer la qualification lors des changements produit pertinents.
04

NELSPACE transforme le raisonnement en dossier vivant.

NELSPACE peut relier les faits produit, le corpus MDR/IVDR retenu, les règles de classification examinées, les cas de référence, les pièces, les responsables et les validations. Une évolution produit peut alors faire ressortir ce qui doit être revu sans effacer l’analyse précédente.

NELSE ne remplace ni le fabricant, ni l’évaluation réglementaire compétente, ni l’organisme notifié lorsqu’il intervient. L’objectif est de rendre le dossier plus structuré, versionné et rejouable.

Sources officielles

Cette page présente une information générale et une méthode de travail. Elle ne constitue pas un avis juridique sur votre situation.

Du texte à votre cas

Montrez-nous ce qui change. Nous montrons ce que NELSE fait examiner, valider et conserver.

Parlons de votre cas

Un parcours concret. Un périmètre clair.

Décrivez votre besoin. Nous préparons un scénario de votre métier et précisons les fonctions, les livrables et les intégrations qui peuvent être examinés ensemble.