Quand on développe un logiciel pour la santé, une question arrive très vite : notre produit est-il un dispositif médical ? Nous nous la sommes posée en développant Doc&Go. La réponse change tout : la façon de concevoir, de documenter, de tester et de mettre le produit sur le marché.
Nous avons choisi de ne pas la traiter à la légère. Nous avons pris le temps de nous former, de lire les textes, et surtout d’apprendre auprès de ceux qui vivent cette réglementation au quotidien. Voici ce que nous en retenons.
Qu’est-ce qu’un dispositif médical ?
En Europe, le dispositif médical (DM) est défini par le règlement (UE) 2017/745, dit MDR, entré en application en mai 2021. Il remplace les anciennes directives et durcit nettement les exigences.
Un DM est un instrument, un appareil, un implant, un matériel ou un logiciel destiné par son fabricant à être utilisé chez l’homme à des fins médicales. Par exemple :
- le diagnostic, la prévention, la surveillance, la prédiction, le pronostic, le traitement ou l’atténuation d’une maladie ;
- le diagnostic, la surveillance, le traitement ou la compensation d’une blessure ou d’un handicap ;
- l’étude, le remplacement ou la modification d’une structure ou d’une fonction anatomique ;
- la communication d’informations au moyen d’un examen in vitro d’échantillons du corps humain.
Le point clé, c’est la destination : l’usage que le fabricant revendique. Deux logiciels très proches techniquement peuvent avoir deux statuts différents selon ce qu’ils promettent de faire.
Quand un logiciel devient un DM
Un logiciel qui stocke, archive, transmet ou affiche simplement des données n’est en général pas un DM. Un logiciel qui traite ces données pour aider à une décision médicale pour un patient précis peut le devenir. On parle alors de logiciel dispositif médical, ou Medical Device Software (MDSW).
Le guide européen MDCG 2019-11 aide à faire cette qualification, étape par étape. Et la règle 11 de l’annexe VIII du MDR fixe la classe du logiciel. Elle est exigeante : un logiciel qui fournit des informations servant à prendre des décisions de diagnostic ou de traitement est au minimum en classe IIa. Il peut monter en IIb, voire en III, si une mauvaise information peut entraîner une dégradation grave de l’état de santé ou un décès.
Dès la classe IIa, un organisme notifié doit évaluer le produit et le système qualité du fabricant avant le marquage CE. C’est un vrai changement d’échelle pour une équipe logicielle.
Ce que cela change pour l’équipe technique
Pour des développeurs, le MDR n’est pas qu’un sujet juridique. Il impose une façon de travailler. Plusieurs normes harmonisées structurent le cycle de vie du produit :
- ISO 13485 : le système de management de la qualité du fabricant ;
- IEC 62304 : le cycle de vie du logiciel, de l’exigence au test, avec une classe de sécurité A, B ou C ;
- ISO 14971 : la gestion des risques, de la conception à la fin de vie du produit ;
- IEC 62366-1 : l’ingénierie de l’aptitude à l’utilisation, pour limiter les erreurs d’usage ;
- IEC 81001-5-1 : la cybersécurité dans le cycle de vie du logiciel de santé.
Concrètement, chaque exigence doit être tracée jusqu’au code et jusqu’aux tests. Chaque risque doit être identifié, évalué et maîtrisé. Chaque version doit être documentée. Il faut une évaluation clinique, un identifiant unique du dispositif (IUD/UDI), un enregistrement dans la base européenne EUDAMED, et une surveillance après commercialisation, avec la matériovigilance auprès de l’ANSM en France.
À cela s’ajoutent les règles propres aux données de santé : le RGPD, et l’hébergement chez un hébergeur certifié HDS en France. Ces contraintes se pensent dès l’architecture. Les ajouter après coup coûte beaucoup plus cher.
Apprendre sur le terrain, avec Newclip Technics
Les textes ne suffisent pas. Pour comprendre comment cette réglementation se vit vraiment, nous avons eu la chance de rencontrer, sur place, les équipes juridiques et réglementaires de Newclip Technics.
Newclip Technics est un fabricant français d’implants et d’instruments d’ostéosynthèse, basé à Haute-Goulaine, près de Nantes. L’entreprise conçoit, fabrique et commercialise des gammes complètes pour les chirurgiens orthopédistes : membre supérieur, membre inférieur, pied et cheville. Elle propose aussi des kits stériles à usage unique et des solutions spécifiques au patient.
Un acteur de cette taille, 100 % fabriqué en France et présent dans plus de 50 pays, vit la conformité réglementaire au quotidien, sur des dispositifs implantables parmi les plus exigeants. C’était exactement le regard dont nous avions besoin.
Ces échanges nous ont permis de nous former aux fondamentaux du DM : la qualification et la classification d’un produit, la logique du dossier technique, la place de la gestion des risques, le rôle de l’organisme notifié, et l’importance de la surveillance une fois le produit sur le marché. Ils nous ont surtout montré une chose : la réglementation n’est pas une étape de fin de projet. C’est un fil rouge, du premier atelier de conception jusqu’au suivi des utilisateurs.
La réglementation n’est pas une étape de fin de projet. C’est un fil rouge, de la conception jusqu’au suivi sur le terrain.
Nous remercions chaleureusement les équipes de Newclip Technics pour leur temps, leur disponibilité et la qualité de leurs explications.
Ce que nous en retenons pour Doc&Go
- Qualifier le produit tôt : la destination revendiquée décide du statut, et donc de tout le reste.
- Concevoir avec la gestion des risques, pas après.
- Tracer les exigences, le code et les tests dès le premier sprint.
- Penser la sécurité et l’hébergement des données de santé dès l’architecture.
- S’entourer de ceux qui ont l’expérience du terrain.
Cette démarche s’applique à Doc&Go, mais elle va bien au-delà. Elle fait désormais partie de la façon dont INOVA accompagne ses clients dans la santé : un logiciel bien construit, mais aussi un logiciel pensé dès le départ pour un cadre réglementaire exigeant.
Vous portez un projet logiciel dans la santé et vous vous demandez s’il relève du dispositif médical ? Parlons-en. Nous serons heureux de partager ce que nous avons appris.