EUDAMED-Readiness: Warum Registrierungen in der Praxis scheitern

EUDAMED wird in vielen Unternehmen noch immer als IT-Projekt behandelt: ein Portal, in das man Daten lädt, sobald die Frist näher rückt. Diese Einordnung ist der Kern des Problems. Die Europäische Datenbank für Medizinprodukte (EUDAMED) ist kein Upload-Tool, sondern der vorgeschriebene Meldeweg für regulatorische Pflichten, die ohnehin bestehen. Seit dem 28. Mai 2026 laufen Vigilanz-Meldungen, der Periodic Safety Update Report (PSUR) und der Post-Market Surveillance Report (PMSR) verpflichtend über die Datenbank. Wer dann keine vollständige Registrierung hat, scheitert nicht an der Technik, sondern an der Frist.

EUDAMED ist Pflicht, nicht Option

Die Rechtsgrundlage steht in Art. 33 der Verordnung (EU) 2017/745 (MDR) für Medizinprodukte und in Art. 30 der Verordnung (EU) 2017/746 (IVDR) für In-vitro-Diagnostika. EUDAMED bündelt sechs Module: Actor-Registrierung, UDI- und Produktregistrierung, Benannte Stellen und Zertifikate, Klinische Prüfungen, Leistungsstudien sowie Vigilanz und Post-Market Surveillance.

Der schrittweise verpflichtende Einsatz dieser Module wurde durch die Verordnung (EU) 2024/1860 scharf geschaltet. Entscheidend ist die Reihenfolge: Die Actor-Registrierung ist die Voraussetzung für jede weitere Tätigkeit in EUDAMED. Ohne sie existiert ein Unternehmen in der Datenbank schlicht nicht, und keine UDI, keine Vigilanz-Meldung und kein Bericht lässt sich einreichen.

Betroffen sind Hersteller, Bevollmächtigte und Importeure aus den Domänen MedTech und IVD. Bei IVD ist zusätzlich die Risikoklasse relevant: Die IVDR staffelt die Übergangsfristen nach Klasse, sodass die Vollpflicht je nach Produkt zu unterschiedlichen Zeitpunkten greift. Genau hier entstehen die ersten Fehleinschätzungen, weil Unternehmen mit gemischtem Portfolio annehmen, eine einzige Frist gelte für alles.

Vier Cluster, an denen Registrierungen hängenbleiben

In Implementierungsprojekten begegnen uns dieselben vier Muster, fast unabhängig von der Unternehmensgröße.

• Lückenhafte Actor-Registrierung. Ohne gültige Single Registration Number (SRN) nach Art. 31 MDR geht nichts weiter. Häufig fehlen die EORI-Nummer oder konsistente Handelsregisterdaten, was den Antrag blockiert. Hersteller außerhalb der EU brauchen zusätzlich einen Bevollmächtigten mit eigener SRN nach Art. 11 MDR. Ist diese Konstellation nicht sauber aufgesetzt, steht das gesamte Projekt still, bevor es begonnen hat.

• Inkonsistente UDI-Daten. Basic UDI-DI und UDI-DI werden verwechselt oder falsch zugeordnet. Produktänderungen, neue Verpackungsgrößen oder Softwareversionen werden nicht zeitnah nachgepflegt, sodass der EUDAMED-Eintrag nicht mehr die tatsächliche Marktversion abbildet. Die UDI-Zuteilung läuft über benannte Zuteilungsstellen wie GS1, HIBCC oder ICCBBA (Durchführungsbeschluss (EU) 2019/939). Bei einer Inspektion wird eine Abweichung zwischen Kennzeichnung, Zertifikatsscope und Datenbankeintrag als Dokumentationsdefizit gewertet, nicht als Bagatelle.

• Vigilanz-Workflow nicht migriert. Viele Hersteller melden schwerwiegende Vorkommnisse und Feldkorrekturmaßnahmen (FSCA) noch per E-Mail an die nationalen Behörden. Seit dem 28. Mai 2026 erfolgt das elektronische Reporting nach Art. 87 MDR über EUDAMED. Die kurzen Meldefristen gelten unverändert. Wer den Workflow nicht umgestellt hat, kann sie über den vorgeschriebenen Kanal formal nicht einhalten, selbst wenn das Vigilanz-Team inhaltlich arbeitsfähig ist. Die Begriffsabgrenzungen dazu hält MDCG 2023-3 fest.

• PMS-Dokumentation nicht uploadfähig. Der PMSR für Klasse I nach Art. 85 MDR und der PSUR für die höheren Klassen nach Art. 86 MDR werden über EUDAMED eingereicht. Inhaltlich gute Berichte sind dabei oft trotzdem nicht kompatibel, weil Struktur und Format nicht den Anforderungen der Datenbank entsprechen. Die Nacharbeit kostet mehr Zeit als erwartet, besonders wenn keine Schnittstelle zum eQMS existiert und alles manuell übertragen werden muss.

Warum die Verwechslung mit einem IT-Projekt teuer wird

Wer EUDAMED als reines Datenproblem versteht, terminiert es falsch. Der zentrale Knackpunkt ist selten der Upload selbst, sondern die Datenqualität: die Konsistenz zwischen Basic UDI-DI, Produktkennzeichnung und dem Scope der Zertifikate. Diese Konsistenz herzustellen ist Regulatory-Arbeit und braucht Vorlauf, weil sie Abstimmung mit der Benannten Stelle, mit dem Qualitätsmanagement und teils mit Lieferanten erfordert.

Hinzu kommt die Dauerhaftigkeit der Pflicht. EUDAMED ist kein einmaliges Projekt mit Abschlussdatum. Produktänderungen, Vigilanz-Meldungen und Berichtszyklen müssen fortlaufend gepflegt werden. Fehlt eine klar benannte Verantwortlichkeit, entstehen genau dort Lücken, die bei der nächsten Inspektion auffallen. Bei größeren Portfolios verschärft sich das Problem, weil manuelle Doppelpflege ohne eQMS-Schnittstelle nicht nur aufwendig, sondern fehleranfällig ist.

Was jetzt zu tun ist

Sinnvoll ist ein modulweiser Soll-Ist-Abgleich, der nach verbleibender Zeit priorisiert. Konkret heißt das:

• SRN zuerst. Actor-Registrierung nach Art. 31 MDR sichern, bei Nicht-EU-Herstellern die Bevollmächtigten-Konstellation nach Art. 11 MDR prüfen. Alles andere baut darauf auf.
• UDI-Daten bereinigen. Mapping von Basic UDI-DI zu UDI-DI, Abgleich mit Kennzeichnung und Zertifikatsscope nach Art. 27 und Art. 29 MDR, dann strukturierte Migration.
• Vigilanz und PMS auf den Meldeweg umstellen. SOPs für Vorkommnis- und FSCA-Meldungen auf das EUDAMED-Reporting nach Art. 87 MDR revidieren, PSUR und PMSR nach Art. 85 und Art. 86 MDR auf Uploadkompatibilität prüfen, vor dem Ernstfall testen.

Entourage begleitet Hersteller, Bevollmächtigte und Importeure aus MedTech und IVD durch alle sechs Module, von der SRN bis zum Vigilanz-Workflow. Der Ausgangspunkt ist meist eine Gap-Analyse, die den Status je Modul festhält und eine realistische Reihenfolge bis zur Erfüllbarkeit der Meldepflichten ableitet. Wo die parallelen Pflichten der IVDR greifen, gilt die gleiche Actor-, UDI- und Vigilanz-Logik, mit Art. 30 IVDR als EUDAMED-Rechtsgrundlage für In-vitro-Diagnostika.