Desde el 28 de mayo de 2026 es obligatorio utilizar el módulo UDI/Devices. Para Regulation Devices cuya primera unidad se introduzca en el mercado de la UE a partir de esa fecha, el registro debe realizarse antes de la introducción en el mercado.

Si la primera unidad ya se había introducido en el mercado antes del 28 de mayo de 2026 y posteriormente se introducen más unidades del mismo Regulation Device o Legacy Device, el calendario oficial de transición señala el 28 de noviembre de 2026 como fecha límite de registro. Esto no permite afirmar de forma general que todos los registros históricos debían estar completamente registrados ya el 28 de mayo.

Fuentes primarias: Comisión Europea – registro UDI/Device · Calendario de transición de UDI/Devices

No, el calendario actual de transición de UDI/Devices no establece para los productos de clase I un plazo especial posterior de carácter general. También en este caso es determinante si la primera unidad se introdujo en el mercado antes del 28 de mayo de 2026 o a partir de esa fecha, y si después se introducen más unidades.

El hecho de que en muchos productos de clase I no intervenga un organismo notificado en el proceso de registro no modifica la obligación del fabricante de registrar el UDI/Device. Los campos de datos realmente necesarios dependen del conjunto de datos MDR, la clase de riesgo y las características del producto.

Fuentes primarias: Calendario de transición de la UE · Registro UDI/Device

Sí. La utilización obligatoria desde el 28 de mayo de 2026 y la lógica de transición descrita en el calendario oficial afectan tanto a situaciones MDR como IVDR. Sin embargo, para un producto IVDR debe utilizarse el conjunto de datos específico de IVDR, que no es idéntico al conjunto de datos MDR.

Por ello, la necesidad y el plazo de registro de un conjunto de datos concreto deben deducirse del estado del producto y de su introducción en el mercado, no de una afirmación general como «todos los IVD antes de una única fecha».

Fuente primaria: Comisión Europea – registro UDI/Device y conjuntos de datos

Para los Legacy Devices cuya primera unidad se introdujo en el mercado antes del 28 de mayo de 2026 y de los que posteriormente se introducen más unidades, la Comisión señala el 28 de noviembre de 2026 como fecha límite de registro.

Los Legacy Devices no se registran con una Basic UDI-DI como los Regulation Devices MDR/IVDR. Para ellos se aplica la lógica EUDAMED DI/EUDAMED ID, que se explica por separado más adelante.

Fuentes primarias: Calendario de transición de la UE · Ayuda de EUDAMED – identificadores de Legacy Devices

Como Economic Operators se gestionan, en calidad de tipos de Actor propios, los fabricantes, representantes autorizados, importadores y productores de Systems/Procedure Packs. El fabricante registra un Regulation Device o Legacy Device; un System o Procedure Pack lo registra el Producer responsable del mismo.

En el caso de un fabricante de fuera de la UE, el registro del Actor es verificado primero por el representante autorizado indicado, que ya debe estar registrado, y después es evaluado por la autoridad competente. Esto debe distinguirse del posterior registro de los productos.

Fuentes primarias: Ayuda de EUDAMED – introducción sobre Actors · Reglas de negocio de UDI/Devices

Sí. Si una organización desempeña varios roles de Actor, debe registrar cada rol por separado. Por tanto, los roles de fabricante e importador reciben registros de Actor y Actor ID/SRN separados.

Antes de realizar una acción, los usuarios vinculados con varios registros de Actor deben seleccionar el contexto de Actor correcto. Así se evita que los registros de productos o las vinculaciones se ejecuten bajo un rol equivocado.

Fuente primaria: Ayuda de EUDAMED – múltiples roles

Un importador con el perfil Linker necesario crea la vinculación desde el panel del importador. Busca al fabricante de fuera de la UE ya registrado, entre otros criterios mediante SRN, nombre o país, introduce las fechas exigidas y confirma la vinculación.

En la secuencia publicada actualmente en la ayuda de EUDAMED no se describe, después de esta confirmación, un paso de aprobación independiente por parte del fabricante. Esta afirmación se refiere al proceso documentado de EUDAMED, no a los acuerdos contractuales entre las empresas.

Fuente primaria: Ayuda de EUDAMED – vincular un fabricante de fuera de la UE con un importador

Seleccione el Actor de fabricante correcto y registre la Basic UDI-DI junto con la primera UDI-DI asociada. Según se trate de MDR o IVDR, se introducen la identificación, las características del producto, otros datos del producto, la información de mercado y, cuando corresponda, las referencias de certificados y las UDI-DI de los envases.

En el proceso documentado, una Basic UDI-DI no puede registrarse sin al menos una UDI-DI asociada. Los campos que aparecen dependen, entre otros factores, del marco jurídico, la clase de riesgo y las respuestas dadas a preguntas previas sobre las características. Incluso para un único producto, los datos deben revisarse técnicamente antes del envío.

Fuentes primarias: Registrar Regulation Devices · Secuencia de pasos para Basic UDI-DI y UDI-DI

Los registros guardados se actualizan mediante «Create new version», siempre que el campo en cuestión sea modificable. El fabricante abre el registro, crea una versión nueva, modifica los datos permitidos y envía esa versión.

Las reglas de los campos no son uniformes: conforme a las reglas de negocio actuales, un Device Name puede añadirse, modificarse y eliminarse. Para un Device Model existen otras restricciones. Los datos identificativos de la Basic UDI-DI no pueden corregirse libremente. Por ello, «Name», «Trade name» y «Model» no deben tratarse como si fueran el mismo campo. Antes de realizar una modificación también debe evaluarse desde el punto de vista regulatorio si el producto sigue perteneciendo a la Basic UDI-DI anterior.

Fuentes primarias: Ayuda de EUDAMED – Create new version · Reglas de negocio de UDI/Devices

Los datos identificativos de una Basic UDI-DI guardada no pueden modificarse libremente como datos maestros ordinarios. Además, EUDAMED comprueba el formato y la unicidad de los identificadores. Un segundo registro no debe utilizarse indebidamente como vía de corrección de un registro existente.

Una UDI-DI idéntica puede aparecer en la situación especial de un Legacy Device y un Regulation Device equivalentes del mismo fabricante; EUDAMED la utiliza entonces para vincular los registros. Esto no constituye un derecho general a utilizar el mismo identificador para productos diferentes. En caso de una asignación errónea, deben comprobarse la causa, el estado de registro y la acción permitida en el sistema antes de crear un registro nuevo.

Fuentes primarias: Información de la Basic UDI-DI · Identificación UDI-DI

En primer lugar se indica si existen advertencias críticas o contraindicaciones. Si se responde «Sí», deben seleccionarse los tipos pertinentes ofrecidos por EUDAMED. Si se elige «Other», se exige una descripción y el idioma correspondiente.

El contenido no debe copiarse de ejemplos genéricos. Son determinantes los datos del producto concreto que hayan sido aprobados y sean coherentes. El sitio web, el etiquetado, las instrucciones de uso, la documentación técnica y el registro de EUDAMED no deberían contradecirse.

Fuente primaria: Ayuda de EUDAMED – características de la UDI-DI

Durante el registro de la Basic UDI-DI, EUDAMED pregunta primero si existe un Device Model. Si se responde «Sí», el modelo es obligatorio y el nombre del producto, si existe, se indica adicionalmente. Si se responde «No», el nombre del producto es obligatorio.

No debe rellenarse el campo con un valor inventado únicamente para superar la validación de un campo obligatorio. Debe corresponder a la identificación real del producto por parte del fabricante. Tenga además en cuenta que las modificaciones posteriores de Model y Name están sujetas a reglas de campo diferentes.

Fuente primaria: Ayuda de EUDAMED – información de la Basic UDI-DI

No existe una única lista breve de campos obligatorios que se aplique por igual a MDR, IVDR y todas las situaciones de Legacy Devices. La Comisión publica conjuntos de datos separados. La obligatoriedad y la visibilidad de cada campo dependen, entre otros factores, del marco jurídico, la clase de riesgo, las características del producto, la obligación de certificación, el estado de mercado y las respuestas anteriores.

Las áreas de datos habituales incluyen la relación Basic UDI/Device, la UDI-DI y la entidad emisora, EMDN, nombre/modelo, características del producto, tipos de UDI-PI, envases, información de mercado, representante autorizado y, cuando proceda, certificados u otras referencias regulatorias. Para una preparación sólida, el conjunto de datos oficial aplicable debe mapearse campo por campo con los datos de origen propios.

Fuente primaria: Comisión Europea – conjuntos de datos MDR, IVDR y Legacy

No, la afirmación general de que «ambos campos de fecha son siempre obligatorios» no es correcta. En las reglas de negocio actuales de UDI/Devices para Data Exchange, las fechas de inicio y fin de Market Information figuran como opcionales.

Deben distinguirse de ellas el estado de mercado, el Estado miembro en el que el producto se introdujo por primera vez en el mercado de la UE y los países en los que se comercializa. Para estos datos se aplican condiciones propias. En el registro manual deben observarse las condiciones que muestre actualmente el formulario y el conjunto de datos oficial adecuado.

Fuentes primarias: Reglas de negocio de UDI/Devices, BR-DTX-UDI-096 · Información adicional del producto

No. El campo describe los Estados miembros o territorios previstos en el conjunto de datos de EUDAMED en los que el producto se comercializa o se comercializará en el mercado de la UE. No es una lista general de todos los países en los que el producto se distribuye a escala mundial.

Para un producto con el estado «On the EU market», este dato es obligatorio según la ayuda actual de EUDAMED para determinadas clases de riesgo; también puede registrarse para otras clases. Un producto no destinado al mercado de la UE puede registrarse con el estado correspondiente. Por ello, el estado y la información sobre países no deben confundirse.

Fuentes primarias: Ayuda de EUDAMED – información de mercado · Reglas de negocio de UDI/Devices

Se refiere al Estado miembro en el que el producto concreto se introdujo o se introducirá por primera vez en el mercado de la UE. El campo no pregunta por el domicilio del fabricante ni por el primer país de venta a escala mundial.

Si el producto no está destinado al mercado de la UE, debe seleccionarse el estado de producto correspondiente. Si se comercializa en el mercado de la UE, el Estado miembro correcto debe derivarse del proceso real de lanzamiento al mercado. El dato no debe rellenarse automáticamente a partir de la dirección del cliente, el importador o la sede de la empresa.

Fuente primaria: Ayuda de EUDAMED – información adicional del producto

Bajo una Basic UDI-DI se agrupan variantes de producto que comparten las mismas características regulatorias básicas esenciales. La ayuda de EUDAMED menciona en particular la misma finalidad prevista, la misma clase de riesgo y características esenciales comparables de diseño y fabricación.

Una Basic UDI-DI puede incluir una o varias UDI-DI, pero no es un grupo cuantitativo ni un contenedor técnico de carga. Por tanto, la pertenencia de dos variantes al mismo grupo no puede decidirse según el número de registros ni con el objetivo de reducir al mínimo el número de archivos XML.

Fuente primaria: Ayuda de EUDAMED – categorización de productos

No. A un Legacy Device no se le asigna una Basic UDI-DI. EUDAMED utiliza en su lugar una EUDAMED DI como elemento de identificación superior para los Legacy Devices y, si no existe UDI-DI, una EUDAMED ID derivada de ella.

Si ya existe una UDI-DI, esta se utiliza para identificar el Legacy Device y EUDAMED genera la EUDAMED DI asociada. Si no existe UDI-DI, el fabricante proporciona la base identificativa necesaria; EUDAMED genera la EUDAMED DI y la EUDAMED ID. Estos identificadores son funcionalmente comparables, pero no equivalen a una Basic UDI-DI asignada por el fabricante a un Regulation Device.

Fuentes primarias: Datos de identificación de Legacy Devices · Generación sin UDI-DI

Si no existe un código adecuado, la FAQ actual de EMDN prevé utilizar el código «99 – Other» correspondiente y presentar una propuesta de modificación justificada mediante la EMDN Submission Platform. Si posteriormente se crea un código nuevo, el fabricante debe actualizar el registro de EUDAMED y la documentación regulatoria asociada.

EMDN se desarrolla mediante un procedimiento público anual. EUDAMED muestra historiales de versiones y puede señalar la necesidad de actualizar códigos retirados, divididos o cuyo alcance se haya reducido. Al mismo tiempo, la Comisión indica que actualmente no es posible notificar individualmente a todos los usuarios afectados. Por ello, las empresas deben supervisar activamente los cambios.

Fuentes primarias: MDCG 2021-12 Rev.2 – preguntas frecuentes sobre EMDN · Comisión Europea – EMDN · Ayuda de EUDAMED – buscar EMDN

No. EUDAMED no menciona Excel como modo de entrada independiente. Oficialmente están disponibles la introducción manual en la interfaz de usuario, la carga de archivos XML conformes con EUDAMED y el Data Exchange M2M. Excel puede utilizarse en una fase anterior como fuente de datos estructurada o plantilla de captura.

En el proceso XML de Europe IT, el cliente completa una plantilla Excel definida. Europe IT valida los datos, genera archivos XML conformes con EUDAMED tras una comprobación satisfactoria y los carga para el cliente mediante el proceso manual de carga XML. La generación de XML, la validación de datos y la carga propiamente dicha son pasos separados.

Fuente primaria para los modos de entrada: Ayuda de EUDAMED – directrices sobre Data Exchange · Servicio de Europe IT: Preparar datos UDI con Excel

No. En XML Bulk Upload, los archivos se generan de forma estructurada y se validan contra los esquemas de EUDAMED, pero, según la Comisión, la carga y descarga siguen siendo acciones manuales del usuario. En M2M Data Exchange, un backend externo se comunica automáticamente con los servicios backend de EUDAMED.

Europe IT utiliza M2M como vía técnica de transmisión dentro de soluciones adecuadas. En el Global Submission Portal el cliente carga la plantilla Excel de Europe IT, recibe una validación automática y, cuando los datos no contienen errores, activa el envío M2M pulsando «Transmitir». En GUDI para SAP el cliente gestiona, valida y aprueba los datos en GUDI y los transmite desde allí a la autoridad mediante M2M. Europe IT no posiciona este servicio como una interfaz estándar aislada e intercambiable dentro del sistema del cliente.

Fuentes primarias: Data Exchange – finalidad · Requisitos previos de M2M

La elección no depende únicamente de 100, 1.000 o cualquier otro número rígido de UDI-DI. Son determinantes la fuente de datos, la estructura Basic UDI/UDI-DI, las relaciones, la calidad de los datos, la frecuencia de repetición, la necesidad de modificaciones, el sistema fuente y el modelo operativo deseado.

• Proceso XML por proyecto: para una transmisión de datos claramente delimitada en la que Europe IT valida los datos de Excel, genera XML y carga manualmente los archivos.
• Global Submission Portal: para flujos de envío recurrentes y controlados por el cliente a partir de la plantilla Excel de Europe IT, con validación automática, transmisión M2M, estado y respuestas de la autoridad.
• GUDI: para gestionar datos UDI en SAP con módulos específicos por autoridad, aprobación, validación y transmisión M2M directa desde GUDI.
• Consultoría y preparación de datos: cuando primero deben aclararse el alcance de productos, el modelo de datos, las responsabilidades o la calidad de los datos.

Encontrará una comparación neutral en Comparar las vías de transmisión de EUDAMED.

Nota: los rangos de cantidades mencionados por la Comisión son orientativos. No sustituyen una evaluación específica del proyecto y de sus condiciones técnicas y operativas.

Compruebe primero el contexto de Actor, el tipo de registro, el filtro de estado y la combinación de filtros de búsqueda. En las vistas de gestión suelen mostrarse de forma predeterminada los borradores; los demás estados deben recuperarse mediante filtros. En la búsqueda general, el registro debe cumplir simultáneamente todas las condiciones de filtro establecidas.

¿Está buscando una Basic UDI-DI, una UDI-DI, una EUDAMED DI o una EUDAMED ID? ¿Se encuentra en el Actor de fabricante correcto? ¿Está consultando la gestión interna o la búsqueda pública? Estas preguntas ofrecen una base más fiable que las suposiciones no documentadas sobre mayúsculas y minúsculas o una supuesta ausencia general de búsqueda parcial.

Fuentes primarias: Gestionar Basic UDI-DI/EUDAMED DI · Buscar y consultar productos

Trate la respuesta como una infracción concreta de una regla y guarde primero el contexto completo. Este incluye el momento de transmisión, Actor, módulo, identificador del registro, campo o ruta XML, valor transmitido, código de error, texto del mensaje y versión del registro.

1. Separe los errores técnicos de formato de los errores de contenido en los datos y de los problemas de autorización o estado.
2. Corrija la fuente afectada, no solamente un archivo XML derivado.
3. Vuelva a validar los campos dependientes y las relaciones.
4. Solo después vuelva a transmitir y compruebe el estado o la respuesta de la autoridad.

En GSP y GUDI, el cliente puede consultar el estado y las respuestas de la autoridad. El cliente corrige los errores técnicos de datos y también activa un nuevo envío. Encontrará mensajes recurrentes y su interpretación en la Biblioteca de errores de EUDAMED.

Nota: un mensaje de error solo demuestra inicialmente que no se ha cumplido una regla concreta del sistema o de negocio. Su causa técnica debe investigarse a partir del registro afectado.

No de forma general. La Comisión explica que, con el inicio obligatorio de un módulo de EUDAMED, finalizan las obligaciones correspondientes derivadas de las directivas anteriores y de su aplicación nacional. Con ello se pretende evitar, en particular, el doble registro de productos y certificados para un mismo proceso de la UE.

Pero esto no significa que EUDAMED sustituya todos los registros, procedimientos de notificación o competencias nacionales para cada rol de mercado y cada situación. Por ejemplo, el MDR permite expresamente a los Estados miembros mantener o introducir disposiciones nacionales sobre el registro de distribuidores. Para obtener una respuesta sólida debe comprobarse la obligación nacional concreta, no solo el nombre de una base de datos.

Fuentes primarias: Comisión Europea – preguntas y respuestas sobre los plazos de transición de EUDAMED · MDR, en particular el artículo 30, apartado 2

Compruebe por separado el país, el rol de mercado, el tipo de producto y la acción de notificación concreta. No pregunte únicamente «¿Sigue existiendo allí una base de datos?», sino, por ejemplo: ¿la obligación afecta al fabricante, importador o distribuidor? ¿Se trata de un registro de Actor, producto, distribución o de otro tipo? ¿Se aplica a productos MDR/IVDR o a un caso especial?

Debe utilizarse como fuente primaria la autoridad nacional competente. El registro de EUDAMED y cualquier obligación nacional restante deben gestionarse en el proceso como sistemas de destino separados. Por ello, esta página no generaliza obligaciones nacionales residuales sin una fuente actual.

Base jurídica de la UE: Reglamento (UE) 2017/745. Para el país concreto también es determinante la publicación actual de su autoridad competente.