EUDAMED FAQ

Seit dem 28. Mai 2026 ist das Modul UDI/Devices verpflichtend zu nutzen. Für Regulation Devices, deren erste Einheit ab diesem Datum auf dem EU-Markt in Verkehr gebracht wird, muss die Registrierung vor dem Inverkehrbringen erfolgen.

Wurde die erste Einheit bereits vor dem 28. Mai 2026 in Verkehr gebracht und werden danach weitere Einheiten desselben Regulation oder Legacy Device in Verkehr gebracht, nennt der offizielle Übergangszeitplan den 28. November 2026 als spätesten Registrierungstermin. Daraus folgt keine pauschale Aussage, dass sämtliche historischen Datensätze bereits am 28. Mai vollständig registriert sein mussten.

Primärquellen: Europäische Kommission – UDI/Device registration · Übergangszeitplan UDI/Devices

Nein, für Klasse-I-Produkte gibt es im aktuellen UDI/Devices-Übergangszeitplan keine pauschale spätere Sonderfrist. Auch hier ist maßgeblich, ob die erste Einheit vor oder ab dem 28. Mai 2026 in Verkehr gebracht wurde und ob danach weitere Einheiten folgen.

Dass bei vielen Klasse-I-Produkten keine Benannte Stelle in den Registrierungsprozess eingebunden ist, ändert nicht die Pflicht des Herstellers zur UDI-/Device-Registrierung. Die tatsächlich erforderlichen Datenfelder richten sich nach MDR-Datensatz, Risikoklasse und Produkteigenschaften.

Primärquellen: EU-Übergangszeitplan · UDI/Device registration

Ja. Die verpflichtende Nutzung ab 28. Mai 2026 und die im offiziellen Zeitplan beschriebene Übergangslogik betreffen sowohl MDR- als auch IVDR-Konstellationen. Für ein IVDR-Produkt ist jedoch der IVDR-spezifische Datensatz anzuwenden; er ist nicht mit dem MDR-Datensatz identisch.

Ob und bis wann ein konkreter Datensatz zu registrieren ist, sollte deshalb aus Produktstatus und Inverkehrbringung abgeleitet werden – nicht aus einer allgemeinen Aussage wie „alle IVDs bis zu einem einzigen Datum“.

Primärquelle: Europäische Kommission – UDI/Device registration und Datensätze

Für Legacy Devices, deren erste Einheit vor dem 28. Mai 2026 in Verkehr gebracht wurde und von denen danach weitere Einheiten in Verkehr gebracht werden, weist die Kommission den 28. November 2026 als spätesten Registrierungstermin aus.

Legacy Devices werden dabei nicht wie MDR-/IVDR-Regulation Devices mit einer Basic UDI-DI registriert. Für sie gilt die EUDAMED-DI-/EUDAMED-ID-Logik, die weiter unten separat erklärt wird.

Primärquellen: EU-Übergangszeitplan · EUDAMED-Hilfe – Legacy identifiers

Als Economic Operators werden Hersteller, Bevollmächtigte, Importeure und System-/Procedure-Pack-Hersteller als eigene Actor-Typen geführt. Die Registrierung eines Regulation oder Legacy Device erfolgt durch den Hersteller; ein System oder Procedure Pack wird durch den dafür verantwortlichen Producer registriert.

Bei einem Nicht-EU-Hersteller wird die Actor-Registrierung zunächst durch den angegebenen, bereits registrierten Bevollmächtigten verifiziert und anschließend von der zuständigen Behörde bewertet. Das ist von der späteren Registrierung der Produkte zu unterscheiden.

Primärquellen: EUDAMED-Hilfe – Actor introduction · UDI/Devices business rules

Ja. Übt eine Organisation mehrere Actor-Rollen aus, muss sie jede Rolle separat registrieren. Hersteller- und Importeurrolle erhalten deshalb getrennte Actor-Einträge und getrennte Actor ID/SRN.

Benutzer, die mit mehreren Actor-Einträgen verbunden sind, müssen vor einer Aktion den richtigen Actor-Kontext auswählen. Das verhindert, dass Produktregistrierungen oder Verknüpfungen unter der falschen Rolle ausgeführt werden.

Primärquelle: EUDAMED-Hilfe – Multiple roles

Ein Importeur mit dem erforderlichen Linker-Profil legt die Verknüpfung im Importer-Dashboard an. Er sucht den registrierten Nicht-EU-Hersteller unter anderem über SRN, Name oder Land, gibt die geforderten Datumsangaben ein und bestätigt die Verknüpfung.

In der aktuell veröffentlichten Schrittfolge der EUDAMED-Hilfe ist nach dieser Bestätigung kein separater Freigabeschritt durch den Hersteller beschrieben. Das ist eine Aussage zum dokumentierten EUDAMED-Ablauf – nicht zu vertraglichen Abstimmungen zwischen den Unternehmen.

Primärquelle: EUDAMED-Hilfe – Linking a non-EU manufacturer to an importer

Sie wählen den richtigen Hersteller-Actor und registrieren die Basic UDI-DI zusammen mit der ersten zugehörigen UDI-DI. Dabei erfassen Sie je nach MDR oder IVDR die Identifikation, Produktmerkmale, weitere Produktinformationen, Marktinformationen und gegebenenfalls Zertifikatsbezüge sowie Verpackungs-UDI-DIs.

Eine Basic UDI-DI kann im dokumentierten Ablauf nicht ohne mindestens eine zugehörige UDI-DI registriert werden. Welche Felder erscheinen, hängt unter anderem von Rechtsrahmen, Risikoklasse und Antworten auf vorgelagerte Merkmalsfragen ab. Auch bei einem einzigen Produkt sollten die Angaben vor dem Absenden fachlich geprüft werden.

Primärquellen: Register Regulation Devices · Schrittfolge Basic UDI-DI und UDI-DI

Registrierte Datensätze werden – soweit das betreffende Feld änderbar ist – über „Create new version“ aktualisiert. Der Hersteller öffnet den Datensatz, erstellt eine neue Version, ändert die zulässigen Angaben und reicht diese Version ein.

Die Feldregeln sind nicht einheitlich: Ein Device Name ist nach den aktuellen Business Rules ergänzbar, änderbar und löschbar. Für ein Device Model gelten andere Einschränkungen. Identifikationsangaben der Basic UDI-DI sind nicht frei korrigierbar. „Name“, „Trade name“ und „Model“ dürfen deshalb nicht als dasselbe Feld behandelt werden. Vor einer Änderung ist außerdem regulatorisch zu beurteilen, ob das Produkt weiterhin zur bisherigen Basic UDI-DI gehört.

Primärquellen: EUDAMED-Hilfe – Create new version · UDI/Devices business rules

Die Identifikationsangaben einer gespeicherten Basic UDI-DI sind nicht wie normale Stammdaten frei änderbar. EUDAMED prüft außerdem Format und Eindeutigkeit von Kennungen. Eine zweite Registrierung darf nicht als Korrekturweg für einen bestehenden Datensatz missbraucht werden.

Eine identische UDI-DI kann in der besonderen Konstellation eines äquivalenten Legacy und Regulation Device desselben Herstellers vorkommen; EUDAMED nutzt sie dann für die Verknüpfung der Datensätze. Das ist kein allgemeines Recht, denselben Identifier für verschiedene Produkte zu verwenden. Bei einer falschen Zuordnung sollten Ursache, Registrierungsstatus und zulässige Systemaktion geprüft werden, bevor ein neuer Datensatz angelegt wird.

Primärquellen: Basic UDI-DI information · UDI-DI identification

Zunächst wird angegeben, ob kritische Warnhinweise oder Kontraindikationen vorhanden sind. Bei „Ja“ sind die zutreffenden, von EUDAMED angebotenen Typen auszuwählen. Wird „Other“ gewählt, ist eine Beschreibung mit Sprache erforderlich.

Die inhaltliche Formulierung darf nicht aus generischen Beispielen übernommen werden. Maßgeblich sind die freigegebenen, konsistenten Produktinformationen des konkreten Medizinprodukts. Website, Kennzeichnung, Gebrauchsanweisung, technische Dokumentation und EUDAMED-Eintrag sollten hierbei nicht widersprüchlich sein.

Primärquelle: EUDAMED-Hilfe – UDI-DI characteristics

In der Basic-UDI-DI-Erfassung fragt EUDAMED zunächst, ob ein Device Model vorhanden ist. Bei „Ja“ ist das Modell verpflichtend und der Produktname wird – sofern vorhanden – zusätzlich angegeben. Bei „Nein“ ist der Produktname verpflichtend.

Das Feld sollte nicht allein deshalb mit einem frei erfundenen Wert gefüllt werden, um eine Pflichtfeldprüfung zu passieren. Es muss der tatsächlichen Produktidentifikation des Herstellers entsprechen. Beachten Sie zudem, dass für spätere Änderungen von Model und Name unterschiedliche Feldregeln gelten.

Primärquelle: EUDAMED-Hilfe – Basic UDI-DI information

Es gibt keine einzige kurze Pflichtfeldliste, die für MDR, IVDR und alle Legacy-Konstellationen gleichermaßen gilt. Die Kommission veröffentlicht getrennte Datensätze. Pflicht und Sichtbarkeit einzelner Felder hängen unter anderem von Rechtsrahmen, Risikoklasse, Produktmerkmalen, Zertifikatspflicht, Marktstatus und vorherigen Antworten ab.

Typische Datenbereiche sind Basic-UDI-/Device-Beziehung, UDI-DI und ausgebende Stelle, EMDN, Name/Modell, Produktmerkmale, UDI-PI-Typen, Verpackungen, Marktinformationen, Bevollmächtigter und – soweit anwendbar – Zertifikats- oder weitere regulatorische Bezüge. Für eine belastbare Vorbereitung sollte der passende offizielle Datensatz feldweise gegen die eigenen Quelldaten gemappt werden.

Primärquelle: Europäische Kommission – MDR-, IVDR- und Legacy-Datensätze

Nein, eine pauschale Aussage „beide Datumsfelder sind immer verpflichtend“ ist nicht richtig. In den aktuellen UDI/Devices-Business-Rules für den Data Exchange sind Start- und Enddatum der Market Information als optional ausgewiesen.

Davon zu unterscheiden sind Marktstatus, der Mitgliedstaat des erstmaligen Inverkehrbringens auf dem EU-Markt und die Länder, in denen das Produkt bereitgestellt wird. Für diese Angaben gelten eigene Bedingungen. Bei der manuellen Erfassung sollten deshalb die aktuell im Formular angezeigten Bedingungen und der passende offizielle Datensatz beachtet werden.

Primärquellen: UDI/Devices business rules, BR-DTX-UDI-096 · Additional device information

Nein. Das Feld beschreibt die Mitgliedstaaten beziehungsweise die im EUDAMED-Datensatz vorgesehenen Gebiete, in denen das Produkt auf dem EU-Markt bereitgestellt wird oder werden soll. Es ist keine allgemeine Liste sämtlicher Länder, in denen ein Produkt weltweit vertrieben wird.

Bei einem Produkt mit Status „On the EU market“ ist diese Angabe nach der aktuellen EUDAMED-Hilfe für bestimmte Risikoklassen verpflichtend; sie kann auch bei anderen Risikoklassen erfasst werden. Ein Produkt, das nicht für den EU-Markt bestimmt ist, kann mit dem entsprechenden Status registriert werden. Status und Länderinformation dürfen daher nicht vermischt werden.

Primärquellen: EUDAMED-Hilfe – market information · UDI/Devices business rules

Gemeint ist der Mitgliedstaat, in dem das konkrete Produkt erstmals auf dem EU-Markt in Verkehr gebracht wurde oder werden soll. Das Feld fragt weder nach dem Sitz des Herstellers noch nach dem ersten weltweiten Verkaufsland.

Ist das Produkt nicht für den EU-Markt bestimmt, ist der entsprechende Produktstatus zu wählen. Wird es auf dem EU-Markt bereitgestellt, muss der tatsächlich zutreffende Mitgliedstaat aus dem Markteinführungsprozess abgeleitet werden. Die Angabe sollte nicht schematisch aus Kundenadresse, Importeur oder Unternehmenssitz befüllt werden.

Primärquelle: EUDAMED-Hilfe – additional device information

Unter einer Basic UDI-DI werden Produktvarianten mit denselben grundlegenden regulatorischen Kerneigenschaften zusammengefasst. Die EUDAMED-Hilfe nennt insbesondere denselben vorgesehenen Zweck, dieselbe Risikoklasse sowie vergleichbare wesentliche Design- und Herstellungsmerkmale.

Eine Basic UDI-DI kann eine oder mehrere UDI-DIs umfassen, ist aber keine Mengengruppe und kein technischer Upload-Container. Ob zwei Varianten zusammengehören, darf daher weder nach Anzahl der Datensätze noch nach dem Wunsch nach möglichst wenigen XML-Dateien entschieden werden.

Primärquelle: EUDAMED-Hilfe – Categorisation of devices

Nein. Eine Basic UDI-DI ist einem Legacy Device nicht zugeordnet. EUDAMED verwendet für Legacy Devices stattdessen eine EUDAMED DI als übergeordnetes Identifikationselement und – wenn keine UDI-DI vorhanden ist – eine daraus abgeleitete EUDAMED ID.

Ist bereits eine UDI-DI vorhanden, wird sie für die Identifikation des Legacy Device verwendet und EUDAMED erzeugt die zugehörige EUDAMED DI. Existiert keine UDI-DI, stellt der Hersteller die erforderliche Identifikationsbasis bereit; EUDAMED erzeugt EUDAMED DI und EUDAMED ID. Diese Kennungen sind funktional vergleichbar, aber nicht mit einer vom Hersteller für ein Regulation Device vergebenen Basic UDI-DI gleichzusetzen.

Primärquellen: Legacy identification details · Generation without UDI-DI

Wenn kein geeigneter Code vorhanden ist, sieht die aktuelle EMDN-FAQ den passenden „99 – Other“-Code sowie einen begründeten Änderungsvorschlag über die EMDN Submission Platform vor. Wird später ein neuer Code geschaffen, muss der Hersteller die EUDAMED-Registrierung und die zugehörige regulatorische Dokumentation aktualisieren.

EMDN wird in einem öffentlichen jährlichen Verfahren weiterentwickelt. EUDAMED zeigt Versionshistorien an und kann bei verworfenen, aufgeteilten oder im Umfang reduzierten Codes auf Aktualisierungsbedarf hinweisen. Die Kommission weist zugleich darauf hin, dass eine individuelle Benachrichtigung aller betroffenen Nutzer derzeit nicht verfügbar ist. Unternehmen sollten Änderungen daher aktiv überwachen.

Primärquellen: MDCG 2021-12 Rev.2 – EMDN FAQ · Europäische Kommission – EMDN · EUDAMED-Hilfe – Search EMDN

Nein. EUDAMED nennt Excel nicht als eigenen Eingabemodus. Offiziell stehen die manuelle Eingabe in der Benutzeroberfläche, der Upload EUDAMED-konformer XML-Dateien und der M2M Data Exchange zur Verfügung. Excel kann vorgelagert als strukturierte Datenquelle oder Erfassungsvorlage dienen.

Im Europe-IT-XML-Prozess füllt der Kunde eine definierte Excel-Vorlage aus. Europe IT validiert die Daten, erzeugt nach erfolgreicher Prüfung EUDAMED-konforme XML-Dateien und lädt diese im manuellen XML-Upload-Prozess für den Kunden hoch. XML-Erzeugung, Datenvalidierung und der eigentliche Upload sind getrennte Schritte.

Primärquelle für die Eingabemodi: EUDAMED-Hilfe – Guidelines on Data Exchange · Europe-IT-Leistung: UDI-Daten mit Excel vorbereiten

Nein. Beim XML Bulk Upload werden Dateien zwar strukturiert erzeugt und gegen EUDAMED-Schemata validiert, das Hochladen und Herunterladen bleibt laut Kommission aber eine manuelle Benutzeraktion. Beim M2M Data Exchange kommuniziert ein externes Backend automatisiert mit den EUDAMED-Backend-Services.

Europe IT nutzt M2M als technischen Übertragungsweg innerhalb geeigneter Lösungen. Im Global Submission Portal lädt der Kunde die Europe-IT-Excel-Vorlage, erhält eine automatische Validierung und löst bei fehlerfreien Daten mit „Übertragen“ die M2M-Submission aus. In GUDI für SAP verwaltet, prüft und gibt der Kunde Daten in GUDI frei und überträgt sie von dort über M2M an die Behörde. Europe IT positioniert dies nicht als beliebige, isolierte Standardschnittstelle im Kundensystem.

Primärquellen: Data Exchange – Purpose · M2M prerequisites

Die Wahl hängt nicht allein von 100, 1.000 oder einer anderen starren Zahl von UDI-DIs ab. Entscheidend sind Datenquelle, Basic-UDI-/UDI-DI-Struktur, Beziehungen, Datenqualität, Wiederholungsrate, Änderungsbedarf, Quellsystem und gewünschtes Betriebsmodell.

• Projektbezogener XML-Prozess: für eine klar abgrenzbare Datenübertragung, bei der Europe IT Excel-Daten validiert, XML erzeugt und die Dateien manuell hochlädt.
• Global Submission Portal: für kundenkontrollierte, wiederkehrende Submission-Workflows aus der Europe-IT-Excel-Vorlage mit automatischer Validierung, M2M-Übertragung, Status und Behördenfeedback.
• GUDI: für UDI-Datenmanagement in SAP mit behördenspezifischen Modulen, Freigabe, Validierung sowie direkter M2M-Übertragung aus GUDI.
• Beratung und Datenaufbereitung: wenn zunächst Produktumfang, Datenmodell, Verantwortlichkeiten oder Datenqualität geklärt werden müssen.

Eine neutrale Gegenüberstellung finden Sie unter EUDAMED-Übertragungswege vergleichen.

Hinweis: Die von der Kommission genannten Mengenbereiche sind Orientierungshilfen. Sie ersetzen keine projektspezifische Bewertung der technischen und operativen Rahmenbedingungen.

Prüfen Sie zuerst Actor-Kontext, Datensatzart, Statusfilter und die Kombination der Suchfilter. In den Verwaltungsansichten werden standardmäßig häufig Entwürfe angezeigt; andere Status müssen über Filter abgerufen werden. In der allgemeinen Suche müssen alle gesetzten Filterbedingungen gleichzeitig zum Datensatz passen.

Suchen Sie eine Basic UDI-DI, eine UDI-DI, eine EUDAMED DI oder EUDAMED ID? Befinden Sie sich im richtigen Hersteller-Actor? Betrachten Sie die interne Verwaltung oder die öffentliche Suche? Diese Fragen sind belastbarer als nicht dokumentierte Annahmen über Groß-/Kleinschreibung oder angeblich grundsätzlich fehlende Teilsuche.

Primärquellen: Manage Basic UDI-DI/EUDAMED DI · Search & View devices

Behandeln Sie die Rückmeldung als konkrete Regelverletzung und sichern Sie zuerst den vollständigen Kontext. Dazu gehören Übertragungszeitpunkt, Actor, Modul, Datensatzkennung, Feld oder XML-Pfad, übermittelter Wert, Fehlercode, Meldungstext und Datensatzversion.

1. Technischen Formatfehler von fachlichem Datenfehler und Berechtigungs-/Statusproblem trennen.
2. Die betroffene Quelle korrigieren – nicht nur eine abgeleitete XML-Datei.
3. Abhängige Felder und Beziehungen erneut validieren.
4. Erst danach neu übertragen und Status beziehungsweise Behördenfeedback kontrollieren.

Im GSP und in GUDI kann der Kunde Status und Behördenfeedback abrufen. Fachliche Datenfehler korrigiert der Kunde; auch eine erneute Submission löst der Kunde aus. Wiederkehrende Meldungen und ihre Einordnung finden Sie in der EUDAMED-Fehlerbibliothek.

Hinweis: Eine Fehlermeldung belegt zunächst nur, dass eine konkrete System- oder Geschäftsregel nicht erfüllt wurde. Ihre fachliche Ursache muss anhand des betroffenen Datensatzes geprüft werden.

Nicht pauschal. Die Kommission erläutert, dass mit dem verbindlichen Start eines EUDAMED-Moduls die entsprechenden Pflichten aus den früheren Richtlinien und ihren nationalen Umsetzungen enden. Damit soll insbesondere eine doppelte Produkt- und Zertifikatsregistrierung für denselben EU-Prozess vermieden werden.

Das bedeutet aber nicht, dass EUDAMED sämtliche nationalen Register, Meldewege oder Zuständigkeiten für jede Marktrolle und jeden Sachverhalt ersetzt. Die MDR erlaubt Mitgliedstaaten beispielsweise ausdrücklich, nationale Vorschriften für die Registrierung von Händlern beizubehalten oder einzuführen. Für eine belastbare Aussage muss daher die konkrete nationale Pflicht und nicht nur der Name einer Datenbank geprüft werden.

Primärquellen: Europäische Kommission – EUDAMED Q&A zu Übergangsfristen · MDR, insbesondere Artikel 30 Absatz 2

Prüfen Sie Land, Marktrolle, Produkttyp und konkrete Meldehandlung getrennt. Fragen Sie nicht nur „Gibt es dort noch eine Datenbank?“, sondern beispielsweise: Betrifft die Anforderung Hersteller, Importeur oder Händler? Geht es um Actor-, Produkt-, Vertriebs- oder eine andere Registrierung? Gilt sie für MDR-/IVDR-Produkte oder einen Sonderfall?

Als Primärquelle sollte die zuständige nationale Behörde verwendet werden. Die EUDAMED-Registrierung und eine verbleibende nationale Pflicht müssen im Prozess als getrennte Zielsysteme geführt werden. Auf dieser Seite werden deshalb keine länderbezogenen Restpflichten ohne aktuelle Quelle verallgemeinert.

EU-Grundlage: Verordnung (EU) 2017/745. Für das konkrete Land ist zusätzlich die aktuelle Veröffentlichung seiner zuständigen Behörde maßgeblich.