EUDAMED & HIBCC

EUDAMED & HIBCC: Does the Plus Sign Belong in the UDI-DI?

An analysis of more than 3 million EUDAMED records reveals a surprising inconsistency in HIBCC UDI-DIs.

Since 28 May 2026, the EUDAMED UDI/Device module has been mandatory. Correct registration of UDI and device data has therefore become a central element of MDR and IVDR compliance for manufacturers.

However, even a seemingly simple field such as the UDI-DI can raise detailed technical questions.

One of these concerns manufacturers using HIBCC as their UDI Issuing Entity:

Does the leading plus sign (+) belong to the UDI-DI submitted to EUDAMED – or should it be omitted?

We analysed the current EUDAMED data set to investigate this question. The result is remarkable.

More than 3 million EUDAMED records analysed

For our analysis, we evaluated a complete EUDAMED data export containing a total of

3,081,594 records

Records with the status “Submitted” were excluded from the analysis.

We then specifically examined records where the Basic UDI-DI begins with ++, indicating a HIBCC structure.

Within this group, the distribution of UDI-DIs is almost exactly 50:50:

58,067 records – 50.8%
Basic UDI-DI begins with ++
UDI-DI does not begin with +

56,247 records – 49.2%
Basic UDI-DI begins with ++
UDI-DI does begin with +

In total, the analysed HIBCC subset therefore comprises 114,314 records.

The result could hardly be more evenly balanced.

Why is the plus sign relevant?

HIBCC uses so-called flag characters within its different identifier structures.

For the Basic UDI-DI, the situation is clear.

HIBCC explicitly defines ++ as the fixed HIBC Basic UDI-DI Flag Character.

A Basic UDI-DI may, for example, look like this:

++A999MODELIDENTIFIER11S8

In this case, ++ is part of the defined Basic UDI-DI structure.

The situation is different for the standard HIBC UDI-DI or Primary Data Structure.

On a label, a HIBC structure may, for example, be represented as follows:

+A999ABC1230V

In addition to the actual Device Identifier, the structure used on the label or in the AIDC context contains additional elements such as the HIBC Flag Character + and a Check Character.

This leads to the key question:

Which characters belong in the regulatory database identifier – and which belong exclusively to the labelling or AIDC structure?

A look at the HIBCC specifications provides an important indication

HIBCC itself illustrates this distinction very clearly in its guidance relating to the FDA’s GUDID database.

In an official HIBCC example, the identifier shown on the product label is:

+A999ABC1230V

However, the Device Identifier entered into the GUDID database is only:

A999ABC1230

The leading + and the Check Character are not included in this database value.

HIBCC therefore explicitly distinguishes between the complete HIBC structure shown on the label and the Device Identifier transmitted to a regulatory database.

This raises an interesting question for EUDAMED: should the same logic be applied consistently?

What do the actual EUDAMED data show?

Our analysis first reveals one very clear finding:

Both formats currently occur in EUDAMED in significant numbers.

However, this does not automatically mean that both variants are regulatorily equivalent or technically equally correct.

Nor does the narrow majority of 50.8% for the format without the plus sign mean that this format must therefore be the correct one.

A majority does not automatically mean that something is correct.

The data also do not allow us to determine why a manufacturer selected one format rather than the other.

Possible reasons may include different interpretations of the HIBCC structure, historical data migrations, different software implementations or different validation logic.

What we can determine, however, is this:

The current EUDAMED data set contains both variants in almost identical proportions.

Does EUDAMED therefore accept both variants?

Precise wording is important here.

Our analysis shows that EUDAMED records containing both variants exist and that, at least among the records we analysed, the format with a leading + was not systematically prevented.

However, this should not automatically be interpreted as meaning that the European Commission has explicitly defined both formats as equivalent alternatives.

Instead, the European Commission refers to the specifications of the respective officially designated UDI Issuing Entities when it comes to UDI formats.

HIBCC is one of these Issuing Entities designated by the European Commission, alongside GS1, ICCBBA and IFA.

The respective HIBCC format specifications are therefore particularly important for the technical interpretation of these identifiers.

Our approach to EUDAMED submissions

In our own EUDAMED submission processes, we use the HIBCC UDI-DI database representation without a leading +.

This decision is not based on the narrow majority identified in our analysis, but on the distinction between the complete HIBC labelling structure and the actual Device Identifier.

The official HIBCC example for GUDID clearly illustrates this distinction.

At the same time, our EUDAMED analysis shows that this interpretation is by no means applied consistently by all market participants.

And from our perspective, this is precisely the key finding of the analysis.

Technically accepted does not automatically mean technically correct

This example highlights a fundamental issue with regulatory UDI databases.

A record may successfully pass technical validation while still raising questions regarding the correct interpretation of an Issuing Entity specification.

For automated M2M or bulk submissions, the only question should therefore not be:

“Has EUDAMED accepted the record?”

An equally important question is:

“Does the transmitted value actually comply with the intended UDI structure of the respective Issuing Entity?”

Especially when dealing with large volumes of data, this distinction can have significant consequences.

What happens if EUDAMED tightens its validation rules in the future?

At present, it is impossible to predict whether the European Commission or HIBCC will further clarify the requirements for representing these identifiers or whether the corresponding EUDAMED Business Rules will be adjusted.

If future validation rules were restricted to a single format, a significant proportion of existing HIBCC records could require review, modification or data cleansing.

With more than 56,000 and 58,000 records respectively for each variant, this would not be a marginal issue.

For this reason, we continuously monitor changes to the EUDAMED Business Rules as well as the technical specifications of the respective UDI Issuing Entities.

Conclusion

Our analysis of more than three million EUDAMED records reveals a remarkable inconsistency in HIBCC UDI-DIs:

50.8% without a leading +
versus
49.2% with a leading +

For us, the narrow majority is not the most important finding.

What matters far more is recognising that regulatory databases require a distinction between technical acceptance, the AIDC/label structure and the actual database identifier to be submitted.

For automated UDI submissions in particular, prior technical and regulatory validation is therefore essential.

Do you have questions about HIBCC UDI-DIs, EUDAMED or automated UDI submissions?

Europe IT Consulting supports medical device companies with the validation, preparation and submission of UDI data – from individual records to automated M2M and bulk data processes.