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.

¿Significa esto que EUDAMED acepta ambas variantes?

En este punto es importante utilizar una formulación precisa.

Nuestro análisis muestra que existen registros de EUDAMED con ambas variantes y que, al menos entre los registros analizados, el formato con un + inicial no ha sido impedido de forma sistemática.

Sin embargo, no debe deducirse automáticamente de ello que la Comisión Europea haya definido expresamente ambos formatos como alternativas equivalentes.

En lo que respecta a los formatos UDI, la Comisión Europea remite a las especificaciones de las respectivas UDI Issuing Entities oficialmente designadas.

HIBCC es una de estas Issuing Entities designadas por la Comisión Europea, junto con GS1, ICCBBA e IFA.

Por este motivo, las especificaciones de formato de HIBCC tienen una importancia especial para la interpretación técnica de estos identificadores.

Nuestro enfoque para los envíos a EUDAMED

En nuestros propios procesos de envío a EUDAMED utilizamos para los UDI-DI de HIBCC la representación para bases de datos sin un + inicial.

Esta decisión no se basa en la estrecha mayoría observada en nuestro análisis, sino en la distinción entre la estructura completa de etiquetado HIBC y el Device Identifier propiamente dicho.

El ejemplo oficial de HIBCC relativo a GUDID ilustra claramente esta diferencia.

Al mismo tiempo, nuestro análisis de EUDAMED demuestra que esta interpretación no se aplica de forma uniforme por todos los participantes del mercado.

Y, desde nuestro punto de vista, esta es precisamente la principal conclusión del análisis.

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 endureciera sus reglas de validación en el futuro?

Actualmente no es posible predecir si la Comisión Europea o HIBCC precisarán en el futuro los requisitos relativos a la representación de estos identificadores o 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

Para nosotros, la estrecha mayoría no es el resultado más importante.

Mucho más importante es reconocer que, en las bases de datos regulatorias, es necesario diferenciar entre la aceptación técnica, la estructura AIDC/de la etiqueta y el identificador de base de datos que realmente debe transmitirse.

Por ello, especialmente en los envíos automatizados de datos UDI, es esencial realizar previamente una validación tanto técnica como regulatoria.

¿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.