EUDAMED & HIBCC: Gehört das Pluszeichen in die UDI-DI?
Eine Analyse von mehr als 3 Millionen EUDAMED-Datensätzen zeigt eine überraschende Inkonsistenz bei HIBCC UDI-DIs.
Seit dem 28. Mai 2026 ist das UDI/Device-Modul von EUDAMED verpflichtend zu verwenden. Für Hersteller ist damit die korrekte Registrierung ihrer UDI- und Produktdaten endgültig zu einem zentralen Bestandteil der MDR- und IVDR-Compliance geworden.
Doch selbst bei einem scheinbar einfachen Feld wie der UDI-DI können Detailfragen entstehen.
Eine davon betrifft Hersteller, die HIBCC als UDI Issuing Entity verwenden:
Gehört das führende Pluszeichen (+) zur UDI-DI, die an EUDAMED übermittelt wird – oder nicht?
Wir haben dazu den aktuellen EUDAMED-Datenbestand analysiert. Das Ergebnis ist bemerkenswert.
Mehr als 3 Millionen EUDAMED-Datensätze analysiert
Für unsere Untersuchung haben wir einen vollständigen EUDAMED-Datenexport mit insgesamt
3.081.594 Datensätzen
ausgewertet. Datensätze mit dem Status „Submitted“ wurden dabei nicht berücksichtigt.
Anschließend haben wir gezielt diejenigen Datensätze untersucht, bei denen der Basic UDI-DI mit ++ beginnt und damit eine HIBCC-Struktur erkennen lässt.
Innerhalb dieser Gruppe ergibt sich bei der UDI-DI nahezu eine 50:50-Verteilung:
58.067 Datensätze – 50,8 %
Basic UDI-DI beginnt mit ++
UDI-DI beginnt nicht mit +
56.247 Datensätze – 49,2 %
Basic UDI-DI beginnt mit ++
UDI-DI beginnt mit +
Insgesamt umfasst die untersuchte HIBCC-Teilmenge damit 114.314 Datensätze.
Das Ergebnis könnte kaum ausgeglichener sein.
Warum ist das Pluszeichen überhaupt relevant?
HIBCC verwendet bei seinen verschiedenen Identifier-Strukturen sogenannte Flag Characters.
Beim Basic UDI-DI ist die Situation eindeutig.
HIBCC definiert ++ ausdrücklich als festen HIBC Basic UDI-DI Flag Character.
Ein Basic UDI-DI kann beispielsweise folgendermaßen aussehen:
++A999MODELIDENTIFIER11S8
Das ++ ist hier Bestandteil der definierten Basic-UDI-DI-Struktur.
Bei der normalen HIBC UDI-DI beziehungsweise Primary Data Structure sieht die Situation anders aus.
Auf einem Label kann eine HIBC-Struktur beispielsweise so dargestellt werden:
+A999ABC1230V
Dabei enthält die auf dem Label beziehungsweise im AIDC-Kontext verwendete Struktur neben dem eigentlichen Device Identifier zusätzliche Elemente wie das HIBC Flag Character + und ein Check Character.
Genau hier entsteht die entscheidende Frage:
Welche Zeichen gehören in den regulatorischen Datenbank-Identifier – und welche ausschließlich zur Kennzeichnungs- beziehungsweise AIDC-Struktur?
Ein Blick auf die HIBCC-Vorgaben liefert einen wichtigen Hinweis
HIBCC selbst zeigt diese Unterscheidung sehr deutlich in seinen Erläuterungen zur FDA-Datenbank GUDID.
In einem offiziellen HIBCC-Beispiel lautet die Kennzeichnung auf dem Produkt:
+A999ABC1230V
Als Device Identifier wird in die GUDID-Datenbank jedoch lediglich
A999ABC1230
eingetragen.
Das führende + und der Check Character sind in diesem Datenbankwert nicht enthalten.
Damit unterscheidet HIBCC ausdrücklich zwischen der vollständigen HIBC-Struktur auf dem Label und dem Device Identifier, der in eine regulatorische Datenbank übertragen wird.
Für EUDAMED stellt sich deshalb die interessante Frage, ob dieselbe Logik konsequent anzuwenden ist.
Was zeigen die tatsächlichen EUDAMED-Daten?
Unsere Analyse zeigt zunächst einmal etwas sehr Konkretes:
Beide Schreibweisen kommen derzeit in EUDAMED in erheblichem Umfang vor.
Das bedeutet allerdings nicht, dass beide Varianten regulatorisch automatisch gleichwertig oder fachlich gleichermaßen korrekt sind.
Und ebenso wenig bedeutet die knappe Mehrheit von 50,8 % für die Schreibweise ohne Pluszeichen, dass diese allein deshalb die richtige Variante sein muss.
Mehrheit bedeutet nicht automatisch richtig.
Aus den Daten lässt sich auch nicht ableiten, warum ein Hersteller eine bestimmte Schreibweise gewählt hat.
Mögliche Ursachen können beispielsweise unterschiedliche Interpretationen der HIBCC-Struktur, historische Datenmigrationen, verschiedene Softwareimplementierungen oder unterschiedliche Validierungslogiken sein.
Was wir jedoch feststellen können:
Die aktuelle EUDAMED-Datenbasis enthält beide Varianten in nahezu identischem Umfang.
Akzeptiert EUDAMED also beide Varianten?
Hier ist eine präzise Formulierung wichtig.
Unsere Analyse zeigt, dass EUDAMED-Datensätze mit beiden Varianten vorhanden sind und dass die Schreibweise mit führendem + zumindest in den von uns untersuchten Datensätzen nicht grundsätzlich verhindert wurde.
Daraus sollte jedoch nicht automatisch abgeleitet werden, dass die Europäische Kommission beide Formate ausdrücklich als gleichwertige Varianten definiert hat.
Die Europäische Kommission verweist bei den UDI-Formaten vielmehr auf die Spezifikationen der jeweiligen offiziell benannten UDI Issuing Entities.
HIBCC gehört neben GS1, ICCBBA und IFA zu diesen von der Europäischen Kommission benannten Issuing Entities.
Gerade deshalb sind die jeweiligen Formatdefinitionen von HIBCC für die technische Interpretation von besonderer Bedeutung.
Unser Ansatz bei EUDAMED-Uploads
In unseren eigenen EUDAMED-Upload-Routinen verwenden wir bei HIBCC UDI-DIs die Datenbankdarstellung ohne führendes +.
Die Entscheidung basiert nicht auf der knappen Mehrheit der von uns gefundenen Datensätze, sondern auf der Trennung zwischen der vollständigen HIBC-Kennzeichnungsstruktur und dem eigentlichen Device Identifier.
Das offizielle HIBCC-Beispiel für die GUDID verdeutlicht genau diese Unterscheidung.
Unsere EUDAMED-Auswertung zeigt gleichzeitig, dass diese Interpretation keineswegs von allen Marktteilnehmern einheitlich umgesetzt wird.
Und genau darin liegt aus unserer Sicht die eigentliche Erkenntnis dieser Analyse.
Technisch akzeptiert bedeutet nicht automatisch fachlich korrekt
Das Beispiel verdeutlicht ein grundsätzliches Thema bei regulatorischen UDI-Datenbanken.
Ein Datensatz kann eine technische Validierung erfolgreich passieren und dennoch Fragen hinsichtlich der korrekten Interpretation einer Issuing-Entity-Spezifikation aufwerfen.
Für automatisierte M2M- oder Bulk-Uploads sollte daher nicht ausschließlich geprüft werden:
„Hat EUDAMED den Datensatz akzeptiert?“
Ebenso wichtig ist die Frage:
„Entspricht der übermittelte Wert tatsächlich der vorgesehenen UDI-Struktur der jeweiligen Issuing Entity?“
Gerade bei großen Datenmengen kann eine solche Unterscheidung erhebliche Auswirkungen haben.
Was passiert, wenn EUDAMED die Validierungsregeln künftig verschärft?
Derzeit lässt sich nicht vorhersagen, ob die Europäische Kommission oder HIBCC die Anforderungen zur Darstellung dieser Identifier künftig weiter präzisieren oder ob entsprechende EUDAMED Business Rules angepasst werden.
Sollten die Validierungsregeln zukünftig auf eine einzige Schreibweise eingeschränkt werden, könnte daraus für einen erheblichen Teil der bereits vorhandenen HIBCC-Datensätze ein Prüfungs-, Änderungs- oder Bereinigungsbedarf entstehen.
Bei mehr als 56.000 beziehungsweise 58.000 Datensätzen je Variante wäre dies kein Randproblem.
Deshalb beobachten wir sowohl Änderungen der EUDAMED Business Rules als auch die technischen Spezifikationen der jeweiligen UDI Issuing Entities kontinuierlich.
Fazit
Unsere Analyse von mehr als drei Millionen EUDAMED-Datensätzen zeigt eine bemerkenswerte Inkonsistenz bei HIBCC UDI-DIs:
50,8 % ohne führendes +
gegen
49,2 % mit führendem +
Für uns ist dabei nicht die knappe Mehrheit das entscheidende Ergebnis.
Viel wichtiger ist die Erkenntnis, dass bei regulatorischen Datenbanken zwischen technischer Akzeptanz, AIDC-/Label-Struktur und dem tatsächlich zu übermittelnden Datenbank-Identifier unterschieden werden muss.
Gerade bei automatisierten UDI-Uploads ist deshalb eine vorgelagerte fachliche und technische Validierung entscheidend.
Sie haben Fragen zu HIBCC UDI-DIs, EUDAMED oder automatisierten UDI-Uploads?
Europe IT Consulting unterstützt Medizintechnikunternehmen bei der Validierung, Aufbereitung und Übermittlung von UDI-Daten – von einzelnen Datensätzen bis zu automatisierten M2M- und Massendatenprozessen.
Related Posts