Quand un logiciel devient-il un dispositif médical ?

Ce n’est pas la technologie qui est déterminante, mais la finalité. Un logiciel est considéré comme un dispositif médical lorsqu’il traite, évalue ou fournit des informations médicales afin d’aider à la prise de décisions diagnostiques ou thérapeutiques. Cela inclut les applications qui analysent des données de santé, évaluent les risques, surveillent des processus physiologiques ou aident les professionnels de santé à prendre des décisions pertinentes.

C’est ce qu’on appelle l’« intended purpose » – la finalité définie par le fabricant – qui est déterminante à cet égard. Celle-ci imprègne l’ensemble de la description du produit : de la documentation technique au mode d’emploi, en passant par la commercialisation. Pour les développeurs, cela signifie qu’il faut clarifier précisément, dès les premières phases du projet, quels sont les avantages médicaux et quelles en sont les implications réglementaires.

Ce que change le RDM

Depuis le 26 mai 2021, les règlements européens sur les dispositifs médicaux (RDM, règlement UE 2017/745) s’appliquent également en Suisse en tant que base juridique contraignante pour la mise sur le marché des dispositifs médicaux, la Suisse ayant transposé les exigences du RDM dans son droit national. Pour les produits existants, des périodes de transition s’appliquent jusqu’à fin 2027 ou 2028, selon la catégorie de risque.

Le RDM poursuit un objectif clair : renforcer la sécurité des patient-e-s, accroître la transparence et améliorer la traçabilité. Ce règlement revêt une importance particulière pour les éditeurs de logiciels, car de nombreuses applications logicielles sont soumises à une évaluation plus stricte dans le cadre du RDM et peuvent désormais être classées dans une catégorie de risque supérieure. Si vous souhaitez approfondir la structure du règlement, ses chapitres, ses annexes et ses exigences, vous trouverez une présentation détaillée sur le site de l’Institut Johner : Règlement sur les dispositifs médicaux (RDM) – tout ce que vous devez savoir.

La règle n° 11 du RDM en est l’élément central : les logiciels fournissant des informations pour des décisions diagnostiques ou thérapeutiques sont en principe classés au minimum dans la classe IIa. En cas de conséquences potentiellement graves, ils peuvent être classés dans les classes IIb ou III. Les logiciels autonomes de classe I, autrefois un modèle courant, n’existeront pratiquement plus.

Concrètement, cela signifie que dès qu’un produit ne relève plus de la classe I, un organisme notifié est nécessaire pour l’évaluation de la conformité. La sécurité et les performances du produit doivent être démontrées, et celui-ci doit faire l’objet d’une documentation et d’un contrôle tout au long de son cycle de vie.

Les principales nouveautés du RDM en bref :

• Exigences accrues en matière d’évaluation clinique et de documentation technique
• Responsabilité élargie du fabricant : responsabilité de bout en bout en matière de conformité et de traçabilité
• Définition élargie des dispositifs médicaux : les logiciels autonomes à usage médical sont explicitement inclus
• Base de données EUDAMED : informations centralisées sur les dispositifs, les entreprises et les essais cliniques
• Obligation d’UDI : identifiant unique du dispositif pour une traçabilité sans faille
• Suivi clinique post-commercialisation (PMCF ou SCAC en français) : collecte systématique de données après la mise sur le marché

Ce que signifie la certification RDM dans la pratique

La certification RDM n’est pas une simple formalité administrative. Elle est le résultat d’un processus continu de développement et d’assurance qualité et doit être prise en compte dès le début.

Les fabricants doivent démontrer que leur produit répond aux exigences essentielles de sécurité et de performance, que les risques sont systématiquement identifiés et maîtrisés, et que la documentation technique est complète et constamment mise à jour.

Concrètement, cela implique :

• Une définition claire de la destination d’utilisation et une classification traçable
• Un système de gestion de la qualité conforme à la norme ISO 13485
• Une documentation technique conforme aux exigences du RDM
• Une gestion des risques tout au long du cycle de vie du produit
• Un développement de logiciels conforme à la norme EN CEI 62304
• Une ingénierie de l'ergonomie selon la norme EN CEI 62366
• Une protection des données, sécurité de l'information et cybersécurité
• Une évaluation clinique et une démonstration de la valeur thérapeutique
• Une surveillance systématique du marché après la mise sur le marché

Dans le domaine des logiciels en particulier, il est essentiel de ne pas considérer les exigences réglementaires comme un simple exercice de documentation a posteriori. Chaque fonctionnalité, chaque modification, chaque mise à jour peut avoir des répercussions sur la catégorie de risque, la validation, l’aptitude à l’emploi et la documentation. Une approche agile reste possible. Cela nécessite toutefois des processus clairs, des rôles bien définis, une gestion rigoureuse des versions et une traçabilité sans faille.

Où se situent les principaux défis ?

Pour les fabricants, le véritable défi consiste à concilier les exigences médicales, réglementaires, techniques et liées aux utilisateurs. Le développement de logiciels dans le domaine des dispositifs médicaux est, par nature, interdisciplinaire. Il exige non seulement de solides compétences en programmation, mais aussi une bonne compréhension de la réglementation, une expertise médicale, des données scientifiques, une gestion de la qualité et une documentation rigoureuse.

Cinq domaines sont particulièrement exigeants :

1. Classification réglementaire précoce : la destination d’utilisation doit être définie dès le début. Si elle est modifiée par la suite, la classification peut changer. Cela a alors des répercussions directes sur l’effort de développement, la documentation, l’évaluation clinique et le parcours de certification.
2. Documentation technique : le RDM exige une documentation nettement plus détaillée que les réglementations antérieures. Elle doit non seulement être disponible au moment de la certification, mais aussi être mise à jour en permanence. Les exigences, les risques, les tests, les versions et les modifications doivent pouvoir être retracés à tout moment.
3. Équilibre entre agilité et réglementation Les logiciels évoluent en permanence, mais dans le domaine des dispositifs médicaux, la rapidité ne doit pas se faire au détriment de la sécurité. Chaque modification doit être évaluée, testée, documentée et validée.
4. Protection des données et cybersécurité Les données de santé comptent parmi les catégories de données les plus sensibles qui soient. La protection des données, les politiques d’accès, la sécurité de l’information et la cybersécurité doivent faire partie intégrante de l’architecture dès le départ et ne pas être ajoutées a posteriori. La Commission européenne mentionne expressément la cybersécurité comme une ligne directrice pertinente pour les logiciels destinés aux dispositifs médicaux.
5. Orientation utilisateur et ergonomie Un logiciel considéré comme un dispositif médical doit être conçu de manière à pouvoir être utilisé en toute sécurité et de façon compréhensible, tant par les professionnels de santé que par les gestionnaires de cas, les responsables RH ou les cadres dirigeants. Un guidage clair de l’utilisateur réduit les erreurs d’interprétation et renforce la qualité des décisions prises à l’aide de l’outil.

La réglementation comme opportunité : ce qu’apporte réellement un processus conforme au RDM

Aussi élevées que soient les exigences, elles apportent également une réelle valeur ajoutée. Un processus de développement conforme aux normes oblige à recenser clairement les exigences, à évaluer systématiquement les risques et à contrôler en permanence la qualité. Cela améliore non seulement le dispositif médical lui-même, mais souvent aussi l’ensemble de la culture de développement logiciel au sein de l’entreprise.

Des processus clairs conduisent à de meilleurs produits : moins d’erreurs, plus de transparence, une meilleure traçabilité. Les utilisateurs gagnent ainsi en confiance et ont la certitude qu’un outil ne se contente pas de fonctionner sur le plan technique, mais qu’il a été développé selon des normes de qualité et de sécurité définies.

Une expertise qui naît à la croisée des disciplines

Le développement d’un logiciel en tant que dispositif médical exige une expérience à plusieurs interfaces à la fois : les exigences médicales doivent être traduites en processus numériques, les prescriptions réglementaires intégrées dans les processus de développement et les besoins des utilisateurs transposés en interfaces compréhensibles.

Un logiciel ne déploie pas ses avantages de manière isolée. Il doit s’intégrer dans des processus réels, s’appuyer sur des connaissances spécialisées et placer l’humain au centre de ses préoccupations. Le développement professionnel de logiciels dans le domaine des dispositifs médicaux va donc au-delà de la simple écriture de code : il implique d’assumer la responsabilité de la qualité, de la sécurité, de la traçabilité et, en fin de compte, de l’efficacité.