Alors qu’EUDAMED est entré dans sa phase obligatoire, deux échéances clés sont désormais à retenir. À compter du 28 mai 2026, tous les nouveaux dispositifs médicaux et dispositifs médicaux de diagnostic in vitro mis sur le marché de l’UE devront être enregistrés dans EUDAMED avant leur mise sur le marché. Pour les dispositifs déjà commercialisés, la date limite est fixée au 28 novembre 2026 ; d’ici là, tous les dispositifs relevant de la législation européenne sur les dispositifs médicaux et les dispositifs médicaux de diagnostic in vitro devront être enregistrés dans le système.
Ce qui apparaît clairement dans l’ensemble du secteur, c’est que la soumission en elle-même n’est pas la seule étape délicate. Le travail en amont – collecte, mise en concordance, structuration et validation des données sous-jacentes – s’avère systématiquement plus complexe et plus chronophage que prévu. Cet article passe en revue les écueils les plus courants rencontrés par les équipes et explique comment les anticiper.
L’une des premières surprises auxquelles certains fabricants sont confrontés est que les informations requises par EUDAMED ne se trouvent pas toutes au même endroit. Les identifiants des dispositifs peuvent figurer dans un système ERP, les détails d’étiquetage dans un PLM, et les informations réglementaires clés être dissimulées dans la documentation technique et les déclarations de conformité. Lorsque ces sources sont regroupées, des incohérences ont tendance à apparaître : des descriptions de produits qui ne correspondent pas aux étiquettes, des codes EMDN qui ont été modifiés ou sont devenus obsolètes, des attributions d’UDI-DI qui n’ont pas suivi le rythme des changements réglementaires.
Les codes EMDN méritent à eux seuls qu’on s’y attarde, car ils sont souvent source de confusion. L’EMDN (nomenclature européenne des dispositifs médicaux) a remplacé le GMDN en tant que système de nomenclature, et les deux ne doivent pas être considérés comme interchangeables ; un code attribué selon une classification basée sur le GMDN ne peut pas être repris tel quel. Au sein d’EUDAMED, le code EMDN saisi pour un dispositif doit se situer au niveau le plus bas de la hiérarchie de la nomenclature ; les codes plus généraux ne sont pas acceptés. De plus, l’EMDN n’est pas statique ; des codes sont périodiquement ajoutés, modifiés ou rendus obsolètes par le biais de publications mises à disposition par la Commission européenne. Il est recommandé de vérifier les fiches des dispositifs à la lumière des dernières mises à jour de l’EMDN avant de finaliser une soumission, car un code qui était correct au moment de la classification initiale peut avoir changé depuis.
Ces incohérences ne constituent pas seulement des inconvénients administratifs. EUDAMED exige une concordance parfaite entre les données soumises, les étiquettes physiques des dispositifs, les notices d’utilisation et la déclaration de conformité. Les divergences doivent être résolues avant qu’une soumission conforme puisse être effectuée. Ce processus de rapprochement prend du temps, souvent bien plus que prévu.
Conséquence pratique : ne considérez pas la collecte de données comme une simple tâche rapide à effectuer avant la soumission. Prévoyez suffisamment de temps dès le début du processus pour procéder à une vérification structurée des données provenant de toutes les sources.
EUDAMED permet la saisie manuelle des données, enregistrement par enregistrement, ce qui peut s’avérer faisable pour des portefeuilles très restreints. Mais cette méthode comporte deux limites fondamentales qui deviennent de plus en plus pesantes à mesure que la taille du portefeuille augmente.
La première est le temps. La saisie manuelle nécessite de parcourir l’interface d’EUDAMED champ par champ, pour chaque dispositif. Avec plus de 100 attributs de données à prendre en compte par enregistrement de dispositif, ce n’est pas une tâche rapide, mais un investissement en temps considérable qui entre en concurrence directe avec le reste de la charge de travail de l’équipe réglementaire. Pour les fabricants disposant d’un portefeuille ne serait-ce que de taille modérée, les heures s’accumulent rapidement.
La seconde est le risque d’erreur. La saisie manuelle implique de traiter de grands volumes de données structurées, attribut par attribut. Même avec les meilleurs processus en place, les conditions ne sont tout simplement pas idéales pour garantir une précision parfaite tout au long du processus. Des erreurs de copier-coller, une valeur saisie dans un champ voisin, un chiffre inversé… ce ne sont pas des signes de négligence, mais une caractéristique inhérente au traitement répétitif de volumes importants de données. Contrairement aux erreurs systématiques, qui ont tendance à être cohérentes et donc plus faciles à repérer, ces incohérences éparses sont difficiles à détecter lors de la révision et leur correction prend beaucoup de temps, car chaque correction nécessite de revenir sur des enregistrements individuels. Cela allonge encore davantage un processus déjà lent.
Il existe trois méthodes pour soumettre des données à EUDAMED : la saisie manuelle, le téléchargement en masse au format XML et l’intégration machine-à-machine (M2M). L’option M2M se connecte directement à EUDAMED via une API et est conçue pour des flux de données automatisés à grande échelle – mais l’infrastructure informatique nécessaire pour la mettre en œuvre de manière fiable est considérable. Dans la pratique, le M2M est l’apanage des grandes multinationales disposant d’équipes techniques dédiées et de systèmes de gouvernance des données bien établis. Pour la grande majorité des fabricants, cela dépasse à la fois leurs besoins et leurs ressources disponibles.
Le téléchargement en masse au format XML s’impose donc comme la solution pratique pour tout portefeuille comptant plus d’une poignée de dispositifs. C’est toutefois là qu’une autre catégorie d’erreurs entre en jeu.
Contrairement aux erreurs humaines qui caractérisent la saisie manuelle, les erreurs de téléchargement en masse ont tendance à être systématiques et liées à des règles. Le mécanisme de téléchargement en masse d’EUDAMED suit une définition de schéma XML (XSD) stricte et applique en outre un ensemble complet de règles métier. Un fichier XML bien formé échouera tout de même à la validation s’il enfreint l’une des dizaines de règles métier. Ces règles régissent les combinaisons de champs, les valeurs autorisées, les exigences conditionnelles et les relations entre les éléments de données.
Les types d’erreurs de validation les plus courants incluent l’oubli de champs obligatoires ou conditionnellement requis. Le modèle de données d’EUDAMED comprend un nombre important de champs qui deviennent obligatoires en fonction d’autres entrées, et ces exigences conditionnelles sont faciles à négliger. Les champs interdépendants posent un défi connexe : des valeurs qui semblent valides prises isolément peuvent être rejetées lorsqu’elles sont évaluées les unes par rapport aux autres. De plus, les erreurs de caractères de contrôle dans les codes UDI-DI de base et UDI-DI, bien qu’apparemment mineures, entraînent des échecs de validation immédiats qui nécessitent une correction à la source.
Chaque échec de téléchargement génère un rapport d’erreur qui doit être interprété, corrigé et soumis à nouveau. La préparation d’un fichier XML conforme à EUDAMED à partir de données sources – généralement structurées dans Excel ou d’autres formats courants – nécessite soit des connaissances en création de fichiers XML, soit un processus de conversion fiable basé sur le XSD d’EUDAMED. Les équipes chargées des affaires réglementaires disposent rarement d’une expertise en langages de balisage, et le recours à des convertisseurs de fichiers génériques produit des résultats qui ne sont pas conformes aux exigences d’EUDAMED.
Pour y parvenir, il ne suffit pas d’un simple outil de conversion, mais d’un outil spécifiquement conçu et testé sur la basedu XSD d’EUDAMED , et capable de mettre en évidence les erreurs de validation d’une manière exploitable par les équipes réglementaires plutôt que par les développeurs.
Une complexité souvent négligée réside dans le fait que les modules d’EUDAMED sont étroitement interdépendants. Les fabricants qui abordent le système comme une série de tâches indépendantes de saisie de données ont tendance à rencontrer des échecs en aval.
La dépendance la plus fondamentale est l’enregistrement de l’acteur (SRN). Sans numéro d’enregistrement unique (SRN) actif et validé, rien d’autre n’est possible : l’enregistrement du dispositif ne peut pas aboutir, les organismes notifiés ne peuvent pas associer les certificats au dossier du fabricant, et les importateurs ne peuvent pas identifier le fabricant dans le système.
La relation entre le module UDI et le module «Certificats» est plus nuancée qu’il n’y paraît. Étant donné que ces deux modules sont soumis à des calendriers de transition différents, il est possible qu’un fabricant télécharge des données UDI-DI de base ainsi qu’un ensemble complet d’enregistrements UDI-DI, et que la soumission soit acceptée sans erreur, mais que le statut ne passe pas de « Soumis » à « Enregistré », car le certificat correspondant n’a pas encore été téléchargé par l’organisme notifié. En l’absence de ce certificat, la fiche du dispositif reste en attente et n’est pas visible dans la base de données publique. Bien qu’il ne s’agisse pas d’un échec de la soumission en soi (« Soumis » est considéré comme un statut conforme), ce n’est pas pour autant la ligne d’arrivée. La solution pratique est simple : coordonnez-vous activement avec votre organisme notifié concernant les délais de téléchargement des certificats, plutôt que de partir du principe que les données seront disponibles lorsque vous en aurez besoin. Découvrir une lacune dans la chaîne de dépendances en cours de processus est une situation gérable si elle est anticipée, mais un retard frustrant si ce n’est pas le cas.
On a souvent tendance à centrer le défi EUDAMED principalement sur les nouveaux dispositifs relevant du MDR/IVDR. Or, la date butoir du 28 novembre 2026 s’applique également aux dispositifs existants – ceux mis sur le marché en vertu de la MDD ou de l’IVDD – avec une nuance importante : un dispositif existant n’a pas besoin d’être enregistré si le même dispositif réglementaire (UDI-DI commun, numéro de catalogue / nom commercial, mêmes caractéristiques) est déjà enregistré en vertu des règlements. Dans la pratique, cette exception est plus restreinte qu’il n’y paraît, et la plupart des dispositifs existants devront tout de même faire l’objet d’un enregistrement spécifique.
L’impact de cette situation se fait sentir de manière inégale au sein du secteur. Les fabricants de dispositifs de diagnostic in vitro (IVD) ont tendance à accuser un retard par rapport aux fabricants de dispositifs médicaux en matière de préparation à EUDAMED (, ce qui s’explique par les délais de transition plus longs prévus par l’IVDR) et, dans certains cas, à s’engager plus tardivement dans la mise en œuvre pratique de la base de données. Au-delà de la dimension spécifique aux dispositifs de diagnostic in vitro, l’enregistrement des dispositifs existants comporte ses propres défis généraux. Les dossiers techniques peuvent être moins structurés, l’historique réglementaire peut être fragmenté entre plusieurs dossiers existants et, en particulier pour les fabricants disposant de portefeuilles établis de longue date, les volumes peuvent être considérables. La planification et l’affectation des ressources doivent tenir compte de ces implications.
Le point commun à tous ces défis est que l’enregistrement UDI sur EUDAMED récompense une préparation précoce et structurée, et pénalise les efforts de dernière minute. Les équipes qui s’en sortent le mieux partagent généralement quelques caractéristiques : elles se sont lancées plus tôt que ce qu’elles jugeaient nécessaire, elles ont consacré du temps à la qualité des données avant de passer à la soumission, et elles disposaient d’une feuille de route technique claire pour le téléchargement des données, avec un recours limité aux solutions manuelles de contournement.
Pour les fabricants qui sont encore en train de définir leur approche, les questions qu’il convient de se poser dès maintenant sont les suivantes : où se trouvent réellement les données relatives à vos dispositifs, et dans quelle mesure sont-elles fiables ? Disposez-vous d’un processus fiable pour convertir ces données dans un format conforme à EUDAMED, capable de gérer l’ensemble des validationsXSD et des règles métier ? Et avez-vous la capacité de gérer cela en parallèle du reste de votre charge de travail réglementaire ?
Si l’une de ces réponses est incertaine, il vaut mieux explorer les options d’assistance le plus tôt possible. Chez Qserve, nous travaillons avec les fabricants pour les décharger de la complexité technique des soumissions EUDAMED – en prenant en charge la structuration des données, la génération XML, la validation et le téléchargement – afin que les équipes réglementaires puissent se concentrer sur ce qu’elles maîtrisent le mieux : l’exactitude et l’exhaustivité des données sous-jacentes.
Les délais sont fixes. La charge de travail est importante. Mais avec une bonne préparation et un accompagnement adapté, il est tout à fait possible de réaliserune soumission EUDAMEDrapide et sans heurts. Contactez-nous pour découvrir comment nous pouvons vous aider.