Dispositif médical logiciel : définition, statut et conséquences

Un logiciel devient un dispositif médical par ce que son fabricant en dit, pas par la technologie qu’il embarque. Le règlement (UE) 2017/745, dit MDR, retient la destination revendiquée : dès qu’un produit annonce une finalité de diagnostic, de prévention, de contrôle, de prédiction, de pronostic, de traitement ou d’atténuation d’une maladie, il entre dans le champ. La conséquence est lourde pour un éditeur, parce qu’elle transforme un projet applicatif en produit réglementé, avec un dossier, un système qualité et une surveillance qui dure toute la vie du produit.

Ce que le règlement appelle un dispositif médical

Le MDR définit le dispositif médical par sa finalité. Un instrument, un appareil, un équipement, un logiciel, un implant ou un matériel destiné par son fabricant à être utilisé chez l’être humain pour une finalité médicale relève du règlement. Le logiciel est cité explicitement, au même rang que le matériel. Il n’existe donc aucun régime allégé pour un produit purement numérique.

Les finalités listées sont le diagnostic, la prévention, le contrôle, la prédiction, le pronostic, le traitement et l’atténuation d’une maladie, ainsi que le diagnostic, le contrôle, le traitement, l’atténuation ou la compensation d’une blessure ou d’un handicap. S’y ajoutent l’investigation, le remplacement ou la modification d’une structure ou d’une fonction physiologique. Une seule de ces finalités suffit à faire entrer le produit dans le champ.

La destination revendiquée décide, pas la technique

La qualification repose sur la destination, c’est-à-dire l’usage auquel le fabricant destine le produit tel qu’il ressort de l’étiquetage, de la notice, des documents commerciaux et de la publicité. Ce que vous écrivez sur votre site et sur votre fiche produit fait donc partie du dossier réglementaire. Un même moteur de calcul peut être un dispositif médical chez un éditeur et un simple outil chez un autre, selon la promesse portée.

Cette règle a une conséquence inconfortable : une équipe commerciale peut faire basculer le statut sans qu’une ligne de code change. Une accroche qui annonce une détection, une alerte sur un risque ou une aide à la décision thérapeutique installe une finalité médicale. Faites relire vos supports de vente par la personne qui tient le dossier réglementaire, au même titre que la notice.

Les logiciels qui restent en dehors du champ

Le MDR ne capte pas tout ce qui touche à la santé. Un logiciel destiné au stockage, à l’archivage, à la communication, à la recherche simple d’une information ou à la compression sans perte n’est pas un dispositif médical tant qu’il n’interprète rien. Un agenda de cabinet, une messagerie sécurisée, un outil de facturation ou une plateforme de prise de rendez-vous restent hors champ.

La frontière se déplace dès qu’une fonction interprète. Un moteur qui déclenche une alerte sur une valeur biologique, qui propose une posologie ou qui produit un score utilisé pour décider d’un examen ne se contente plus de transmettre. Le fait que la décision finale revienne au professionnel de santé n’écarte pas le statut : le règlement vise l’information fournie en vue d’une décision.

• Hors champ en principe : archivage, transmission, agenda, facturation, prise de rendez-vous, recherche documentaire.
• Hors champ également : les applications de bien-être qui ne revendiquent aucune finalité médicale.
• Dans le champ : calcul de dose, aide au diagnostic, score de risque exploité en clinique, tri de patients, interprétation d’images ou de signaux.
• Dans le champ aussi : un module d’alerte greffé sur un logiciel par ailleurs hors champ, quand ce module poursuit une finalité médicale.

Ce que le statut change dans la vie du produit

Devenir fabricant de dispositif médical ne se résume pas à apposer un logo. Vous devez qualifier puis classer le produit, tenir un système de management de la qualité, gérer les risques sur tout le cycle de vie, constituer une documentation technique, mener une évaluation clinique, signer une déclaration UE de conformité, vous enregistrer avec votre dispositif, puis surveiller le produit après sa mise sur le marché.

Les délais changent aussi de nature. Sur un logiciel classique, une correction part en production dans la journée. Sur un dispositif médical, chaque modification passe par une analyse d’impact : la version livrée doit rester couverte par le dossier, et un changement significatif peut appeler une nouvelle évaluation. Cette contrainte se conçoit dès l’architecture, en isolant les fonctions réglementées du reste de l’application.

Modules, accessoires et découpage du produit

Un produit n’est pas nécessairement dispositif médical dans son intégralité. Le MDR admet qu’un logiciel comporte des modules qui poursuivent une finalité médicale et d’autres qui n’en poursuivent aucune. Les premiers relèvent du règlement, les seconds non, à condition que la séparation soit réelle : interfaces documentées, données identifiées, tests distincts, versions maîtrisées. Sans frontière démontrable, l’ensemble est traité comme un dispositif.

Un logiciel peut aussi être un accessoire de dispositif médical, par exemple une application qui pilote un objet connecté médical ou qui en restitue les mesures pour un usage clinique. L’accessoire suit le régime du règlement, avec sa propre classification. Ce découpage se décide au moment du cahier des charges, parce qu’il fixe le périmètre du dossier, donc le coût et le calendrier.

Comment nous vous accompagnons

Nous intervenons au moment où la question se pose vraiment, c’est-à-dire au cadrage. Nous passons vos revendications au crible, fonction par fonction, pour établir ce qui relève du règlement et ce qui peut rester en dehors. Quand le produit se prête à un découpage, nous concevons l’architecture qui rend la séparation démontrable, avec des interfaces documentées et des versions maîtrisées. Nous développons ensuite la partie réglementée en suivant IEC 62304 et nous préparons les éléments logiciels du dossier. Pour cadrer votre cas : contact@digitalunicorn.fr ou 06 32 64 24 80.

Digital Unicorn développe des applications de santé pour des éditeurs et des établissements, en appliquant les référentiels décrits ci-dessus. Nous ne sommes ni un organisme notifié, ni un hébergeur certifié : nous concevons le logiciel, nous produisons la documentation attendue et nous travaillons avec l’hébergeur agréé et l’organisme d’audit que vous choisissez. Avis technique gratuit de trente minutes au 06 32 64 24 80 ou à contact@digitalunicorn.fr, et le guide du développement d’application santé pour la vue d’ensemble.