EUDAMED 2026
Für Medizinprodukte- und IVD-Hersteller bedeutet die verpflichtende Nutzung vor allem eines: Akteurs-, UDI- und Produktdaten müssen nicht nur korrekt gemeldet, sondern dauerhaft beherrscht werden. Wer EUDAMED als einmaliges Registrierungsprojekt behandelt, verschiebt das eigentliche Problem nur.
EUDAMED & UDI bei AENUMA · Regulatorische Fristen · EUDAMED Datenpflege
Seit dem 28. Mai 2026 ist die Nutzung der ersten vier als funktionsfähig erklärten EUDAMED-Systeme verpflichtend. Dazu gehören die Akteursregistrierung, die UDI-/Produktregistrierung, das Modul für Benannte Stellen und Bescheinigungen sowie das Modul zur Marktüberwachung. Für Hersteller sind vor allem die eigene Akteursregistrierung und die UDI-/Produktregistrierung operativ relevant.
Das ändert den Charakter von EUDAMED grundlegend: Aus einem bislang teilweise freiwillig genutzten System wird ein verbindlicher Bestandteil regulatorischer Prozesse. Damit reicht es nicht mehr, Daten für eine einmalige Meldung zusammenzutragen. Hersteller müssen sicherstellen, dass Produktdaten auch nach Änderungen konsistent, nachvollziehbar und rechtzeitig aktualisiert werden können.
Die schwierigste Frage lautet in der Praxis selten: Wer kann ein Feld im Portal ausfüllen? Schwieriger sind Fragen wie: Welches System ist für dieses Feld führend? Wer darf den Wert ändern? Wer genehmigt die Änderung? Welche Folgeprozesse werden dadurch ausgelöst? Und wie wird nachgewiesen, dass EUDAMED anschließend denselben Stand enthält?
Ein Produktname kann im ERP stehen, die Risikoklasse in einem Regulatory-System, die Verpackungshierarchie in Excel und der Zertifikatsbezug im Dokumentenmanagement. Solange das Produkt unverändert bleibt, fällt diese Fragmentierung kaum auf. Bei einer neuen Variante, einer Verpackungsänderung oder einer geänderten regulatorischen Einstufung wird daraus ein Abstimmungsproblem.
Deshalb sollte EUDAMED als Datenprozess verstanden werden: Das Portal ist das regulatorische Zielsystem. Die eigentliche Datenqualität entsteht vorher.
Je nach Produkt und regulatorischer Konstellation müssen unterschiedliche Daten zusammengeführt werden. Typische Bereiche sind Organisations- und Akteursinformationen, Basic UDI-DI und UDI-DI, Produktidentität, Varianten und Verpackungsebenen, regulatorische Klassifizierung, EMDN-Zuordnung, Statusinformationen und Verknüpfungen zu Bescheinigungen.
Nicht jede Information muss im ERP entstehen. Entscheidend ist vielmehr, dass für jeden Datentyp eine führende Quelle und ein fachlicher Owner definiert sind.
Grundlage: Basic UDI-DI und UDI-DI unterscheiden
| Datentyp | Typische führende Quelle | Typische Verantwortung |
|---|---|---|
| Artikel, Varianten, Verpackung | ERP / Product Master | Operations / Stammdaten |
| Basic UDI-DI, UDI-DI | Regulatory Data / Product Master | Regulatory Affairs |
| Risikoklasse, EMDN | Regulatory Master Data | Regulatory / Quality |
| Organisation, SRN | Compliance / Stammdaten | Regulatory / Legal |
| Zertifikatsbezug | QMS / Regulatory Data | Quality / Regulatory |
| Freigaben und Änderungen | Workflow / Change Control | prozessabhängig |
Excel ist für Analyse, Bereinigung und Migration hervorragend geeignet. Kritisch wird es, wenn eine Datei dauerhaft die einzige Stelle ist, an der regulatorische Produktdaten zusammengeführt und verändert werden. Dann entsteht neben ERP, QMS und Regulatory-Systemen ein zusätzlicher Datenhaushalt.
Das hat drei typische Folgen. Erstens müssen Änderungen mehrfach gepflegt werden. Zweitens ist unklar, welches System im Konfliktfall recht hat. Drittens wird der Nachweis einer kontrollierten Änderung schwieriger, weil Freigabe, Historie und Verantwortlichkeit häufig außerhalb eines definierten Workflows liegen.
Das Ziel sollte deshalb nicht „Excel abschaffen“ heißen. Das Ziel lautet: Excel darf Analysewerkzeug sein, aber nicht die ungeklärte Master-Datenbank für einen regulatorisch relevanten Prozess.
„Seit Mai verpflichtend“ bedeutet nicht, dass jede historische Information am selben Tag vollständig nachregistriert sein musste. Für bestimmte Bestandsprodukte bestehen Übergangsregelungen und Nachregistrierungsfristen. Für die operative Planung sollte daher mindestens zwischen neuen Produkten, bereits in EUDAMED registrierten Produkten und Bestandsprodukten unterschieden werden.
Für Hersteller ist besonders wichtig, die eigene Produktpopulation zu segmentieren. Eine pauschale Liste „EUDAMED offen“ hilft wenig. Besser ist eine Matrix, die je Produktfamilie zeigt: regulatorischer Status, benötigte Daten, Datenquelle, Datenlücken, verantwortliche Person und spätestes Zieldatum.
Vertiefung: Bestandsprodukte und die Frist 27. November 2026
EUDAMED unterstützt verschiedene Wege der Datenübermittlung. Neben der manuellen Eingabe über die Benutzeroberfläche stehen strukturierte Upload- beziehungsweise Datenaustauschwege zur Verfügung. Welcher Weg wirtschaftlich sinnvoll ist, hängt nicht nur von der Anzahl der Produkte ab.
Bei wenigen Produkten und seltenen Änderungen kann eine kontrollierte manuelle Pflege sinnvoll sein. Bei größeren Portfolios, vielen Varianten oder häufigen Änderungen steigt der Nutzen strukturierter Übertragung. Eine Machine-to-Machine-Integration lohnt sich allerdings erst, wenn das interne Datenmodell stabil ist. Eine Schnittstelle automatisiert sonst lediglich Inkonsistenzen.
Vertiefung: EUDAMED per UI, XML oder Machine-to-Machine
Ein robustes Zielbild trennt operative und regulatorische Verantwortung, ohne zwei unabhängige Wahrheiten zu erzeugen. Operative Artikel-, Varianten-, Verpackungs-, Chargen- und Serieninformationen können beispielsweise im ERP entstehen. Regulatorische Attribute werden dort gepflegt, wo Regulatory Affairs sie fachlich verantwortet. Ein kontrollierter Datenfluss verbindet beide Welten und überträgt freigegebene Informationen an EUDAMED.
In einer Microsoft-Landschaft kann das beispielsweise bedeuten: Dynamics 365 als operativer Core, Dataverse für regulatorische Attribute und fachliche Anwendungen, Power Platform für Freigaben und Ausnahmebehandlung sowie eine definierte Übertragung nach EUDAMED.
Wichtig ist dabei nicht das konkrete Tool. Entscheidend ist die Regel: Jedes relevante Feld hat genau eine führende Quelle.
Der häufig unterschätzte Anwendungsfall ist nicht die Erstregistrierung, sondern die Änderung danach. Ändert sich beispielsweise eine Verpackungsebene, eine Produktvariante oder ein regulatorisches Merkmal, muss klar sein, ob und wann dadurch eine Änderung in EUDAMED erforderlich wird.
Ein sinnvoller Change-Control-Prozess beantwortet deshalb fünf Fragen: Was wurde geändert? Welche regulatorischen Daten sind betroffen? Welche Systeme müssen aktualisiert werden? Wer prüft und genehmigt die Änderung? Und wie wird bestätigt, dass die Übertragung erfolgreich war?
Erst wenn dieser Prozess definiert ist, wird aus einer erfolgreichen Registrierung ein dauerhaft beherrschter EUDAMED-Prozess.
Ist EUDAMED seit 28. Mai 2026 verpflichtend?
Ja. Seit diesem Datum ist die Nutzung der ersten vier als funktionsfähig erklärten EUDAMED-Systeme verpflichtend. Welche konkreten Pflichten für ein Produkt gelten, hängt jedoch von Produktstatus und regulatorischer Situation ab.
Müssen alle UDI-Daten im ERP gepflegt werden?
Nein. Sinnvoll ist eine klare Trennung nach fachlicher Entstehung. Operative Produktdaten gehören typischerweise in ERP oder Product Master; regulatorische Attribute können in einem Regulatory Master oder Dataverse geführt werden. Entscheidend ist eine eindeutige führende Quelle.
Brauchen Hersteller eine EUDAMED-Schnittstelle?
Nicht zwingend. Der Nutzen hängt von Produktanzahl, Änderungsfrequenz, Datenqualität und Prozessvolumen ab. Vor einer technischen Integration sollte das Datenmodell geklärt sein.
Reicht eine einmalige Datenbereinigung?
Nein. Datenqualität muss als laufender Prozess organisiert werden. Sonst entstehen nach der nächsten Produktänderung erneut Abweichungen zwischen ERP, Regulatory-Daten und EUDAMED.
Die nachhaltige Lösung ist kein isoliertes Portalprojekt. Sie verbindet operative Produktdaten, regulatorische Attribute, Freigaben, Änderungskontrolle und Übertragung. EUDAMED bleibt das regulatorische Zielsystem; die Datenpflege wird dort organisiert, wo Daten fachlich entstehen und verantwortet werden.
Nächster Schritt: EUDAMED-Readiness-Check oder EUDAMED- und UDI-Daten im System.
Weiterlesen: UDI im ERP. Wo sollten regulatorische Produktdaten entstehen?
Weitere Fachbeiträge zu EUDAMED, UDI und ERP
Europäische Kommission: EUDAMED Überblick
Europäische Kommission: UDI/Device Registration
EUR-Lex: Verordnung (EU) 2024/1860
Stand: 17. August 2026. Organisatorische und technische Einordnung, keine rechtliche Einzelfallprüfung.
