
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 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 currently accept both variants?
From a technical perspective: yes.
Our analysis shows that HIBCC UDI-DIs can currently be registered in EUDAMED both with and without a leading +.
However, this does not mean that the European Commission has explicitly defined both variants as technically or regulatorily equivalent.
Based on the current situation, EUDAMED’s technical validation does not clearly exclude either of the two formats. As a result, both variants can currently be submitted and registered from a technical perspective.
The key question is therefore not which variant EUDAMED technically accepts, but which format will ultimately be defined as mandatory.
The issue is being discussed further at EU level
The different use of the leading + is no longer merely a theoretical formatting question.
According to the information currently available to us, the issue has also been taken up at EU level and is expected to be addressed in one of the upcoming discussions or meetings.
This may provide clarification on which representation of HIBCC UDI-DIs will be mandatory in EUDAMED in the future and whether the technical validation rules will need to be adjusted accordingly.
To the best of our current knowledge, no final decision has yet been made.
For this reason, we believe it is important to clearly distinguish between what is currently technically possible in EUDAMED and what may ultimately be defined as the required format.
What would a possible change mean for our customers?
If the European Commission or EUDAMED introduces a clear mandatory format for HIBCC UDI-DIs in the future, already registered records may need to be adjusted.
If UDI data previously submitted by us on behalf of our customers are affected by such a change, we will perform the required conversion for our customers free of charge.
We continuously monitor further developments, changes to the EUDAMED Business Rules and the relevant technical requirements so that we can respond accordingly as soon as a clear rule is published.
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 adjusts its validation rules in the future?
At present, it is not yet possible to say conclusively which representation of HIBCC UDI-DIs will ultimately be defined as mandatory or whether corresponding EUDAMED Business Rules will be changed.
If future validation rules are 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 both changes to the EUDAMED Business Rules and 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 +
The most important finding is not which variant currently occurs more frequently.
What matters is that EUDAMED currently allows both formats from a technical perspective, while this does not automatically constitute a final technical or regulatory assessment of both variants.
Further clarification of this formatting issue therefore remains relevant – especially if a clear validation rule is introduced in the future.
If this results in required changes to UDI data previously submitted by Europe IT Consulting for our customers, we will perform the necessary conversion free of charge.
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.
Get in contact with us








Related Posts