EUDAMED & HIBCC

EUDAMED & HIBCC

EUDAMED & HIBCC: ¿Debe incluirse el signo más en el UDI-DI?

Un análisis de más de 3 millones de registros de EUDAMED revela una sorprendente inconsistencia en los UDI-DI de HIBCC.

Desde el 28 de mayo de 2026, el uso del módulo UDI/Device de EUDAMED es obligatorio. Por lo tanto, el registro correcto de los datos UDI y de los productos se ha convertido definitivamente en un elemento central del cumplimiento del MDR y del IVDR para los fabricantes.

Sin embargo, incluso un campo aparentemente sencillo como el UDI-DI puede plantear cuestiones técnicas de detalle.

Una de ellas afecta a los fabricantes que utilizan HIBCC como UDI Issuing Entity:

¿Debe formar parte del UDI-DI transmitido a EUDAMED el signo más inicial (+) o debe omitirse?

Para investigar esta cuestión, hemos analizado el conjunto actual de datos de EUDAMED. El resultado es destacable.


Más de 3 millones de registros de EUDAMED analizados

Para nuestro análisis, evaluamos una exportación completa de datos de EUDAMED que contenía un total de

3.081.594 registros

Los registros con el estado «Submitted» no se incluyeron en el análisis.

A continuación, examinamos específicamente aquellos registros en los que el Basic UDI-DI comienza con ++, lo que permite identificar una estructura HIBCC.

Dentro de este grupo, la distribución de los UDI-DI es prácticamente de 50:50:

58.067 registros – 50,8 %
El Basic UDI-DI comienza con ++
El UDI-DI no comienza con +

56.247 registros – 49,2 %
El Basic UDI-DI comienza con ++
El UDI-DI sí comienza con +

En total, el subconjunto HIBCC analizado comprende 114.314 registros.

El resultado difícilmente podría estar más equilibrado.


¿Por qué es relevante el signo más?

HIBCC utiliza los denominados Flag Characters dentro de sus diferentes estructuras de identificadores.

En el caso del Basic UDI-DI, la situación está clara.

HIBCC define expresamente ++ como el HIBC Basic UDI-DI Flag Character fijo.

Por ejemplo, un Basic UDI-DI puede tener el siguiente aspecto:

++A999MODELIDENTIFIER11S8

En este caso, ++ forma parte de la estructura definida del Basic UDI-DI.

La situación es diferente en el caso del UDI-DI HIBC estándar o de la Primary Data Structure.

En una etiqueta, una estructura HIBC puede representarse, por ejemplo, de la siguiente manera:

+A999ABC1230V

Además del Device Identifier propiamente dicho, la estructura utilizada en la etiqueta o en el contexto AIDC contiene elementos adicionales, como el HIBC Flag Character + y un Check Character.

Y es precisamente aquí donde surge la cuestión clave:

¿Qué caracteres deben formar parte del identificador transmitido a una base de datos regulatoria y cuáles pertenecen exclusivamente a la estructura de etiquetado o AIDC?


Las especificaciones de HIBCC ofrecen una indicación importante

HIBCC muestra claramente esta distinción en sus explicaciones relativas a la base de datos GUDID de la FDA.

En un ejemplo oficial de HIBCC, el identificador que aparece en la etiqueta del producto es:

+A999ABC1230V

Sin embargo, el Device Identifier introducido en la base de datos GUDID es únicamente:

A999ABC1230

El + inicial y el Check Character no están incluidos en este valor de la base de datos.

Por lo tanto, HIBCC distingue expresamente entre la estructura HIBC completa que aparece en la etiqueta y el Device Identifier que se transmite a una base de datos regulatoria.

Esto plantea una cuestión interesante en relación con EUDAMED: ¿debe aplicarse de forma coherente la misma lógica?


¿Qué muestran los datos reales de EUDAMED?

Nuestro análisis muestra, en primer lugar, un resultado muy concreto:

Ambos formatos aparecen actualmente en EUDAMED en cantidades significativas.

Sin embargo, esto no significa automáticamente que ambas variantes sean equivalentes desde el punto de vista regulatorio ni igualmente correctas desde el punto de vista técnico.

Tampoco significa que la estrecha mayoría del 50,8 % correspondiente al formato sin signo más implique que esta variante deba ser necesariamente la correcta.

Una mayoría no significa automáticamente que algo sea correcto.

Los datos tampoco permiten determinar por qué un fabricante ha elegido un formato determinado.

Entre las posibles razones podrían encontrarse diferentes interpretaciones de la estructura HIBCC, migraciones históricas de datos, distintas implementaciones de software o diferentes lógicas de validación.

Sin embargo, sí podemos constatar lo siguiente:

El conjunto actual de datos de EUDAMED contiene ambas variantes en proporciones prácticamente idénticas.


¿Acepta EUDAMED actualmente ambas variantes?

Desde un punto de vista técnico: sí.

Nuestro análisis muestra que actualmente los UDI-DI de HIBCC pueden registrarse en EUDAMED tanto con como sin un + inicial.

Sin embargo, esto no significa que la Comisión Europea haya definido expresamente ambas variantes como equivalentes desde el punto de vista técnico o regulatorio.

Según la situación actual, la validación técnica de EUDAMED no excluye claramente ninguno de los dos formatos. Como resultado, actualmente ambas variantes pueden transmitirse y registrarse desde un punto de vista técnico.

Por lo tanto, la cuestión clave no es qué variante acepta técnicamente EUDAMED, sino qué formato se definirá finalmente como obligatorio.


La cuestión continúa debatiéndose a nivel de la UE

El uso diferente del + inicial ya no es únicamente una cuestión teórica de formato.

Según la información de la que disponemos actualmente, el tema también ha sido planteado a nivel de la UE y se espera que sea abordado en una de las próximas reuniones o deliberaciones.

Esto podría aportar claridad sobre qué representación de los UDI-DI de HIBCC será obligatoria en EUDAMED en el futuro y si las reglas de validación técnica deberán adaptarse en consecuencia.

Hasta donde llega nuestro conocimiento actual, todavía no se ha adoptado una decisión definitiva.

Por este motivo, consideramos importante distinguir claramente entre lo que actualmente es técnicamente posible en EUDAMED y lo que finalmente pueda definirse como formato obligatorio.


¿Qué significaría un posible cambio para nuestros clientes?

Si en el futuro la Comisión Europea o EUDAMED establecen un formato obligatorio y claramente definido para los UDI-DI de HIBCC, podría ser necesario adaptar registros que ya estén registrados.

Si los datos UDI que hayamos transmitido previamente en nombre de nuestros clientes se ven afectados por dicho cambio, realizaremos gratuitamente para nuestros clientes la conversión necesaria.

Supervisamos continuamente la evolución de este tema, los cambios en las Business Rules de EUDAMED y los requisitos técnicos pertinentes, de modo que podamos reaccionar en consecuencia tan pronto como se publique una regla clara.


Que un dato sea técnicamente aceptado no significa automáticamente que sea técnicamente correcto

Este ejemplo pone de manifiesto una cuestión fundamental relacionada con las bases de datos regulatorias de UDI.

Un registro puede superar con éxito una validación técnica y, aun así, plantear dudas sobre la correcta interpretación de las especificaciones de una Issuing Entity.

Por lo tanto, en los envíos automatizados mediante M2M o procesos bulk, la única pregunta no debería ser:

«¿Ha aceptado EUDAMED el registro?»

Igualmente importante es preguntarse:

«¿Cumple realmente el valor transmitido con la estructura UDI prevista por la correspondiente Issuing Entity?»

Especialmente cuando se manejan grandes volúmenes de datos, esta distinción puede tener consecuencias significativas.


¿Qué ocurriría si EUDAMED modificara sus reglas de validación en el futuro?

Actualmente todavía no es posible afirmar de forma definitiva qué representación de los UDI-DI de HIBCC se establecerá como obligatoria ni si se modificarán las correspondientes Business Rules de EUDAMED.

Si las futuras reglas de validación se limitaran a un único formato, una parte significativa de los registros HIBCC ya existentes podría requerir revisión, modificación o depuración de datos.

Con más de 56.000 y 58.000 registros respectivamente para cada variante, no se trataría de un problema marginal.

Por este motivo, supervisamos continuamente tanto los cambios en las Business Rules de EUDAMED como las especificaciones técnicas de las respectivas UDI Issuing Entities.


Conclusión

Nuestro análisis de más de tres millones de registros de EUDAMED revela una notable inconsistencia en los UDI-DI de HIBCC:

50,8 % sin un + inicial
frente a
49,2 % con un + inicial

La conclusión más importante no es qué variante aparece actualmente con mayor frecuencia.

Lo decisivo es que EUDAMED permite actualmente ambas variantes desde un punto de vista técnico, sin que ello suponga automáticamente una evaluación técnica o regulatoria definitiva de ambas opciones.

Por tanto, sigue siendo relevante una futura aclaración de esta cuestión de formato, especialmente si más adelante se introduce una regla de validación claramente definida.

Si como consecuencia de ello fuera necesario modificar datos UDI previamente transmitidos por Europe IT Consulting para nuestros clientes, realizaremos gratuitamente la conversión necesaria.

¿Tiene preguntas sobre los UDI-DI de HIBCC, EUDAMED o los envíos automatizados de datos UDI?

Europe IT Consulting ayuda a las empresas de tecnología médica en la validación, preparación y transmisión de datos UDI, desde registros individuales hasta procesos automatizados M2M y procesos masivos de datos.

Ponte en contacto con nosotros
Ugur Müldür

Ugur Müldür leads Sales & Marketing activities at Europe IT Consulting GmbH in Basel, Switzerland. With an industrial engineering background, he bridges regulatory requirements, business needs, and IT implementation for UDI programs. He works with MedTech manufacturers to improve data quality, streamline submissions, and operationalize UDI solutions across global regulations.