Publicité en cours de chargement...
Comprendre ce qu’implique le marquage CE des DM
19 mars 2024 - 09:49,
Communiqué
- Computer Engineering,Management de la qualité et maîtrise des risques
Quel point commun entre une seringue et un logiciel de gestion des prescriptions et préparations à l’hôpital ? Tous deux sont des dispositifs médicaux et, à ce titre, sont soumis à la législation spécifique de l’Union européenne, notamment le nouveau règlement européen (2017/745). En revanche, ce nouveau règlement entraine une reconsidération de la classe des DM, et ils doivent donc répondre à des contraintes différentes. « Actuellement, nos logiciels sont marqués CE dans la classe de risque I, explique Thomas Lecardez, responsable qualité chez Computer Engineering. Maintenant nous mettons en place les procédures pour entrer dans la classe II et obtenir un nouveau marquage CE dans cette catégorie de risque. »
Pour être en conformité avec cette évolution réglementaire, Computer Engineering vise le marquage CE en classe II pour ses deux logiciels Pharma et Chimio. « Le marquage CE est indispensable lorsqu’un dispositif médical intervient dans la sécurité du patient, note Jean-François Tournamille, pharmacien du service Expertise Médicale de Computer Engineering. C’est un effort très important pour obtenir le marquage en classe II, car les dossiers de préparation sont extrêmement complexes. Chez nous, cela mobilise deux personnes à temps plein et concerne l’ensembles des collaborateurs ».
Les fabricants et éditeurs bénéficient d’un délai de mise en conformité prévu jusqu’en 2028.
Les prérequis avant le marquage CE ont été tout d’abord l’obtention de la certification ISO 9001 puis ISO 13485, système de management de la qualité des DM. De plus, la réglementation demande de répondre à la norme ISO 62304 pour le développement des logiciels.
Voilà donc trois ans que les équipes de Computer Engineering préparent ces étapes. La certification ISO 13485 a été validée par un organisme accrédité, et fera l’objet d’audits de contrôle annuels.
Matériovigilance pour les utilisateurs
Les conséquences pour les utilisateurs sont moins lourdes que pour les éditeurs de logiciels, mais elles existent néanmoins. La maîtrise du risque exige aussi une intervention des personnels de santé. Explications de Jean-François Tournamille : « Dans le cadre de la réglementation, nous devons gérer les suspicions de dysfonctionnement des DM, émises soit directement par les utilisateurs, soit par notre cellule de test, ou encore via les déclarations faites à l’ANSM, puis envoyer des alertes aux établissements de santé. Les centres utilisateurs ont ensuite l’obligation d’en accuser réception, afin d’attester qu’ils ont bien pris en compte l’information et pris les mesures pour limiter tout risque patient. Ceci est d’autant plus important que la mise en œuvre des versions correctives demande une phase de qualification par les utilisateurs, la période « à risque » de transition est donc plus importante que lorsqu’il s’agit d’un médicament ou d’un DM à remplacer dans les services.»
Si les équipes sont rompues à exercer la pharmacovigilance pour les médicaments, la matériovigilance pour des dispositifs médicaux « consommables », rares sont celles qui ont pris le réflexe de renvoyer ces accusés de réception de matériovigilance, comme le constate Jean-François Tournamille : « C’est pourtant essentiel. Pour chaque incident sur un DM, nous établissons en plus des déclarations règlementaires auprès de l’ANSM et de l’EMA, une fiche de sécurité avec le type de problème, le paramétrage concerné, les solutions de contournement à appliquer pour garantir le bon fonctionnement en attendant la mise à disposition des correctifs. Si l’utilisateur ne respecte pas les solutions de contournement proposées et qu’il y a ensuite un problème, sa responsabilité sera engagée. L’accusé de réception prouve que tout le monde a bien pris connaissance de l’information. »
Même si le délai de mise en conformité est accordé jusqu’en 2028, les équipes de Computer Engineering mettent tout en œuvre pour y parvenir en 2026. Car pendant cette période de transition, seuls de petits aménagements seront possibles sur les logiciels, aucun développement important n’est autorisé sur les fonctionnalités concernant la sécurité du patient. Raccourcir le délai, c’est donc garantir aux équipes de soins une réactivité plus forte pour répondre à leurs futures demandes.