UDI-Verwaltung und EUDAMED-Einträge automatisieren

Das echte Ausmaß des Problems

Seit dem 28. Mai 2026 sind die ersten vier EUDAMED-Module Pflicht, darunter Akteur-Registrierung und UDI-Datenbank mit Produktregistrierung. Die Kommission hat ihre Funktionsfähigkeit mit Beschluss (EU) 2025/2371 festgestellt, veröffentlicht am 27.11.2025, die Pflichten gelten sechs Monate danach. Jeder Hersteller, der Medizinprodukte in der EU vermarktet, muss sich als Akteur registrieren und für jede Produktkonfiguration einen eigenen UDI/Device-Eintrag anlegen, und aktuell halten. Neue Produkte brauchen den Eintrag, bevor sie in Verkehr gebracht werden (Art. 29 MDR). Für Produkte, die schon auf dem Markt sind und weiter in Verkehr gebracht werden, läuft die Frist zwölf Monate nach der Veröffentlichung, also bis Ende November 2026 (Art. 123 Abs. 3 Buchst. e MDR). Die CE-Kennzeichnung hängt nicht am Eintrag, das Inverkehrbringen schon.

Die Komplexität liegt in der Struktur: Je Produkt gibt es in der Regel nicht einen Eintrag, sondern mehrere. Eine Klasse-IIa-Produktfamilie mit vier Größen, drei Materialien und zwei Verpackungseinheiten kommt auf 24 einzelne UDI-DI-Einträge, plus den gemeinsamen Basis-UDI-DI. Wer 50 Produktfamilien hat, steht vor potenziell mehreren hundert Einzeleinträgen, jeder mit über 50 Pflichtfeldern.

Der Aufwand ist erheblich. Nach Kalkulationen von tracekey solutions GmbH (2024), einem Anbieter von EUDAMED-Software, liegt der manuelle Aufwand bei 15 Minuten pro UDI-Eintrag bei einem Stundensatz von 25 Euro, das sind 6,25 Euro je Eintrag nur für die Dateneingabe, ohne Fehlerkorrektur und Nacharbeiten. Bei 300 Einträgen sind das 300 mal 15 Minuten, also 75 Stunden reine Tipparbeit.

Die Fehlerquellen sind vielfältig und weniger offensichtlich, als man denkt:

• Copy-Paste-Fehler zwischen ERP, Excel-Templates und EUDAMED-Webformular, besonders bei alphanumerischen Codes (UDI-DI, EMDN-Code) mit ähnlichen Zeichenfolgen
• Fehlende Felder in der Produktdokumentation: EUDAMED fragt Attribute ab, die in vielen QM-Systemen gar nicht strukturiert vorliegen, z. B. ob das Produkt steril ausgeliefert wird, ob es Latexanteile enthält, ob es reimplantierbar ist
• Sequenzierungsprobleme in EUDAMED selbst: Die EUDAMED-Validierungspipeline hat eine dokumentierte technische Abhängigkeit zwischen UDI-DI-Stammdaten und dem Marktinformations-Snapshot, wer die falsche Reihenfolge trifft, erhält kryptische Fehlermeldungen und landet in einem Ablehnungsloop (Quelle: europe-it-consulting.ch, Februar 2026)
• Versionskonflikte: Wenn das Produkt zertifiziert und danach geändert wird, ist unklar, ob ein neuer UDI-DI nötig ist oder nur ein Update des bestehenden Eintrags (MDCG 2018-1 rev. 4 regelt, welche Änderungen eine neue UDI-DI auslösen)

ACKOMAS, ein auf EUDAMED-Compliance spezialisiertes Beratungsunternehmen, nennt in einem Leitfaden (September 2025) aus Erfahrung einen Kipppunkt um 200 UDI-DIs, schreibt aber ausdrücklich, dass die Menge allein irreführt: Wer häufig ändert, in neue Märkte geht oder unter Auditdruck steht, ist mit manueller Pflege schon deutlich darunter schlecht beraten.

Das Timing ist ungünstig: Viele Hersteller, die bis 2025 auf EUDAMED „gewartet” haben (die Datenbank hatte seit 2020 mehrere Verzögerungen), stehen jetzt mit einem Rückstau von Registrierungen vor einem System, das in der Lernphase ist. Beratungskapazitäten bei Dienstleistern sind stark ausgelastet.

Mit vs. ohne KI, ein ehrlicher Vergleich

¹ Annahmen dieser Seite, keine Messung. Die 30–60 Minuten enthalten Erfassung und Prüfung, tracekey rechnet für die reine Eingabe mit 15 Minuten. Eine belastbare Fehlerquote für EUDAMED-Einreichungen haben wir nicht gefunden.

Der Unterschied liegt weniger in der Rohgeschwindigkeit der Dateneingabe als in der Fehlerrate und in der Skalierung: Ein Mensch, der denselben Datensatz zum dritten Mal kopiert, macht Kopierfehler. Ein System, das aus einer sauberen Quelle exportiert, macht diese Fehler nicht, dafür übernimmt es jeden Fehler der Quelle zuverlässig in alle Varianten.

Einschätzung auf einen Blick

Zeitersparnis, hoch (4/5)
Bei 50 Produktkonfigurationen spart ein automatisierter Workflow nach den Annahmen der Tabelle 50 mal 20 bis 50 Minuten, also rund 17 bis 42 Arbeitsstunden pro Registrierungswelle. Auf einer Jahresbasis können mit Änderungen 80–150 Stunden zusammenkommen, das entspricht bei rund 1.700 Jahresstunden 5–9 Prozent einer Vollzeitstelle, die nur für EUDAMED-Datenpflege aufgewendet wird. Zeit 4 (nicht 5), weil der Aufwand für Einrichtung, Datenmigration und laufende Qualitätsprüfung nicht verschwindet, er verlagert sich vom Tippaufwand zur Systembetreuung.

Kosteneinsparung, niedrig (2/5)
Die direkten Kosteneinsparungen sind real, aber nicht dominierend: weniger Personalaufwand für Dateneingabe, weniger Korrekturrunden. Was fehlt, ist eine große Einmalinvestition oder laufende externe Kosten, die durch das System ersetzt werden. Im Vergleich zu anderen Anwendungsfällen in der Medizintechnik, etwa der Technischen Dokumentation nach MDR, wo KI kapitalintensive Dokumentationsarbeit beschleunigt, ist die monetäre Einsparung hier enger gefasst und weniger spektakulär.

Schnelle Umsetzung, hoch (4/5)
Kein spezielles Training, keine Hardware, keine lange Zertifizierung. Der EUDAMED Playground der EU-Kommission ist kostenlos, braucht einen EU-Login und ermöglicht Testkonfigurationen vor der Echtumgebung. Tools wie mytracekey UDI Manager sind SaaS-Lösungen ohne komplexes Onboarding. Ein Pilotbetrieb mit 10–20 Produktkonfigurationen ist in 6–10 Wochen realistisch. Einstieg 4 (nicht 5), weil die Datenmigration und das Mapping auf EUDAMED-Felder mehr Aufwand erzeugen, als man zunächst annimmt, oft liegt ein spürbarer Teil der Pflichtfelder nicht strukturiert vor.

ROI-Sicherheit, sehr hoch (5/5)
Das ist die stärkste Achse dieses Anwendungsfalls. Anders als bei KI-Projekten, bei denen der Nutzen indirekt gemessen werden muss, ist er hier direkt zählbar: Anzahl EUDAMED-Einträge mal Zeitaufwand pro Eintrag, bei hunderten Einträgen eine echte Stichprobe. Jede Registrierung, die nicht in einem Korrekturdurchgang landet, spart messbare Zeit. ROI 5 im Branchenvergleich ist gerechtfertigt.

Skalierbarkeit, sehr hoch (5/5)
Dieser Anwendungsfall hat ein besonderes Skalierungsprofil: Jede neue Produktvariante, jedes neue Marktland, jede Zertifizierungsperiode erzeugt neue EUDAMED-Einträge. Mit manuellem Prozess wächst der Aufwand linear mit dem Portfolio. Mit einem automatisierten System bleibt der Mehraufwand pro neuer Variante konstant niedrig, das System kennt das Mapping, die Validierungsregeln, die Datenstruktur. Wer heute 50 Konfigurationen hat und in drei Jahren 200, bezahlt für die 150 neuen Einträge nicht proportional mehr. Skalierbarkeit 5 im Branchenvergleich ist gerechtfertigt.

Richtwerte, stark abhängig von Portfoliogröße, vorhandener ERP/PLM-Infrastruktur und Häufigkeit von Produktänderungen.

Die EUDAMED-Struktur verstehen: Akteur zuerst, Produkt danach

Bevor jedes Werkzeug sinnvoll ist, muss ein konzeptioneller Punkt klar sein: EUDAMED funktioniert in zwei getrennten Schritten, und viele Hersteller scheitern am ersten, nicht weil der Schritt schwer wäre, sondern weil er übersehen wird.

Schritt 1, Actor Registration (Akteur-Registrierung)
Jeder Hersteller, der Produkte in der EU vermarktet, muss sich zunächst als wirtschaftlicher Akteur in EUDAMED registrieren. Das Ergebnis ist eine Single Registration Number (SRN). Ohne validierte SRN lässt EUDAMED keine Device-Registrierung zu, wer diesen Schritt verzögert, hat hinterher das Problem, dass Produkteinträge nicht eingereicht werden können, obwohl die Daten bereits fertig sind.

Nicht-EU-Hersteller brauchen einen EU-Bevollmächtigten (Authorised Representative nach Art. 11 MDR), der zuerst registriert sein muss, bevor der Hersteller selbst eingetragen wird. Diese Abhängigkeit sorgt regelmäßig für Verzögerungen, wenn das Mandat mit dem Bevollmächtigten zu spät vereinbart wird.

Schritt 2, Device Registration (Produkt-Registrierung)
Erst mit validierter SRN können Produkteinträge erstellt werden. Je Eintrag gibt es zwei Ebenen:

• Basis-UDI-DI: Der übergeordnete Identifier für eine Produktfamilie, der die gemeinsamen Merkmale aller Varianten beschreibt
• UDI-DI (Device Identifier): Der spezifische Code für jede einzelne Produktkonfiguration, jede Größe, jede Verpackungseinheit, jedes Sterilisationsverfahren bekommt seinen eigenen UDI-DI

Der UDI-PI (Production Identifier), also Chargennummer, Seriennummer, Herstellungsdatum, wird dagegen nicht in EUDAMED eingetragen. Er erscheint auf dem Produktetikett und im Vertriebssystem, aber nicht in der Datenbank. Das ist ein häufiges Missverständnis: Wer den gesamten UDI-String inklusive PI in EUDAMED einzutragen versucht, scheitert an der Validierung.

KI-gestützte Systeme können bei beiden Schritten helfen: Checklisten für die Akteur-Registrierung, Vollständigkeitsprüfung der SRN-Dokumentation, danach strukturierte Datenerfassung für die Device-Registration mit Vorab-Validierung.

Was das System konkret macht

Die Automatisierung von EUDAMED-Einträgen ist kein einzelnes KI-Modell, sondern ein Prozess mit mehreren Stufen. Jede davon kann mit unterschiedlicher Tiefe technisch unterstützt werden:

Stufe 1, Extraktion aus Produktdokumentation
Ein LLM liest Produktspezifikationen, technische Dateien und Datenblätter und zieht die EUDAMED-relevanten Felder heraus: Handelsname, Risikoklasse, EMDN-Code, Sterilisationsverfahren, Einmalverwendung, Latexinhalte, Abmessungen. Die Felder müssen auf die exakten EUDAMED-Codewerte gemappt werden. Ein LLM kann plausible Codes vorschlagen, ein Mensch muss verifizieren. Wie viel der Feldarbeit die Extraktion abnimmt, hängt an der Struktur eurer Unterlagen, den Rest klären Fachleute.

Stufe 2, Vollständigkeitsvalidierung vor der Einreichung
Bevor ein Datensatz an EUDAMED gesendet wird, prüft das System alle Pflichtfelder auf Vollständigkeit, die referenzierten Zertifikatsnummern auf Gültigkeit und die UDI-DI-Struktur auf formale Korrektheit. Fehler, die EUDAMED nach der Einreichung mit kryptischen Meldungen zurückgeben würde, werden vorher identifiziert, mit klarer Beschreibung, was fehlt.

Stufe 3, Generierung von XML-Exportdateien
EUDAMED unterstützt Bulk-Upload über XML-Dateien. Anstatt jedes Produkt manuell in die Weboberfläche einzutippen, generiert das System valide XML-Dateien, die direkt hochgeladen werden können. Das beseitigt Tippfehler bei der Übertragung und spart den größten Teil der Eingabezeit.

Stufe 4, Änderungsmanagement mit Benachrichtigung
Wenn ein Produkt nach der Registrierung geändert wird, ohne dass eine neue UDI-DI nötig ist, etwa bei geänderten Angaben zum Produkt, muss der Datensatz in der UDI-Datenbank binnen 30 Tagen aktualisiert sein (MDR Anhang VI Teil C Abschnitt 5.8). Verlangt die Änderung eine neue UDI-DI, etwa eine neue Verpackungsgröße, wird ein neuer Eintrag fällig, bevor das Produkt in Verkehr geht. Ein automatisiertes System erkennt Änderungen in der Produktdokumentation und löst eine Benachrichtigung aus: „Diese Änderung erfordert eine EUDAMED-Aktualisierung bis zum [Datum].”

Stufen 1 bis 3 lassen sich mit spezialisierten EUDAMED-Tools und ergänzendem LLM-Einsatz umsetzen. Stufe 4 erfordert eine Integration mit dem internen Änderungsmanagement, das ist technisch möglich, aber aufwendiger und lohnt sich erst ab einem gewissen Änderungsvolumen.

Die EUDAMED-API-Realität: Was Machine-to-Machine wirklich bedeutet

Wer über EUDAMED-Automatisierung liest, stößt schnell auf den Begriff Machine-to-Machine (M2M), die vollständige Systemintegration, bei der das ERP direkt mit EUDAMED kommuniziert, ohne manuellen Export. Das klingt nach dem idealen Endstatus, und technisch ist es das auch. Die Realität ist nüchterner:

M2M-Integration erfordert die Einrichtung eines eDelivery Access Points, eine technische Infrastrukturkomponente, die der europäischen Nachrichtensicherheitsarchitektur folgt. Die EU-Kommission beschreibt den Prozess in ihrer Dokumentation explizit: Die Kommission wird nicht bei der Software-Vorbereitung und nicht bei den Systemintegrationen zwischen dem Access Point und dem jeweiligen ERP helfen. Wer M2M anstrebt, braucht IT-Ressourcen und typischerweise einen spezialisierten Dienstleister.

mytracekey UDI Manager schätzt in öffentlichen Kostenkalkulationen, dass der M2M-Weg erhebliche Vielfache der Bulk-Upload-Option kosten kann. Das ist für Hersteller mit 50 oder 200 Produkten kaum vertretbar.

Die praktische Alternative für die meisten mittelständischen Hersteller ist der XML-Bulk-Upload: Das System generiert valide XML-Dateien, die ein Mensch einmal pro Woche oder Monat in EUDAMED hochlädt. Keine vollständige Automatisierung, aber der größte Teil der Eingabearbeit fällt weg, ohne den Infrastrukturaufwand der M2M-Integration.

Die Empfehlung für die Praxis: Mit XML-Bulk-Upload starten, M2M-Integration als optionalen nächsten Schritt evaluieren, sobald das System stabil läuft und das Änderungsvolumen es rechtfertigt.

Datenqualität als Voraussetzung

Kein EUDAMED-Automatisierungssystem ist besser als die Produktdaten, die es verarbeitet. Das ist die wichtigste Lektion aus frühen Implementierungen, und gleichzeitig die größte Fehlerquelle.

EUDAMED fragt über 50 Felder je Produkt ab. Viele davon sind Attribute, die in klassischen ERP-Systemen oder Produktakten nicht explizit vorhanden sind:

• EMDN-Code: Welche Hersteller haben den bisher strukturiert vergeben?
• Einmalverwendung als explizites Boolean-Feld: Steht das in der Produktspezifikation so oder nur implizit im Produktnamen?
• Latexinhalt und DEHP-Inhalt: Liegt das in der technischen Dokumentation strukturiert vor oder als Freitext in einem Gutachten?
• Abmessungen in cm (nicht mm, nicht Zoll): Sind die Angaben einheitlich?

Ein LLM kann diese Informationen aus Freitext-Dokumenten extrahieren, aber mit begrenzter Zuverlässigkeit. Eine Messung speziell für EUDAMED-Produktattribute kennen wir nicht. Den nächsten Anhaltspunkt liefert der Preprint „Benchmarking LLM-based Information Extraction Tools for Medical Documents” (Yu, Weile, Courtot, medRxiv, Januar 2026): Auf 1.000 fiktiven medizinischen Dokumenten erreichte das beste Modell (GPT-4.1-mini) einen durchschnittlichen F1-Wert von 55,6. Andere Dokumente, andere Aufgabe, nicht begutachtet, aber ein deutliches Zeichen, dass Vollautomatik nicht trägt.

Das macht KI nicht nutzlos, aber es definiert die sinnvolle Rolle: nicht als vollautomatischen Eingabe-Roboter, sondern als Vorerfassungssystem, das Felder vorbefüllt und die offenen oder unsicheren Attribute für menschliche Prüfung markiert. Jedes vorbefüllte Feld prüft ein Mensch gegen die Quelle.

Für Hersteller, deren Produktdaten in einer Mischung aus Word-Dokumenten, Excel-Tabellen und PDFs ohne konsistente Felddefinitionen vorliegen, empfiehlt sich vor dem EUDAMED-Projekt ein Datenpflicht-Mapping: Welche EUDAMED-Felder fehlen strukturiert in der Produktdokumentation? Diese Lücken müssen geschlossen werden, entweder durch Rückerfassung oder durch Festlegung, welcher Prozess diese Daten künftig produziert.

Konkrete Werkzeuge, was wann passt

Der sinnvolle Werkzeugansatz hängt stark von der Unternehmensgröße, dem Portfolioumfang und der vorhandenen IT-Infrastruktur ab.

mytracekey UDI Manager , wenn du eine dedizierte EUDAMED-Lösung ohne ERP brauchst
Spezialisierte SaaS-Lösung ausschließlich für UDI-Management und EUDAMED. Vorab-Validierung, XML-Export, optionale M2M-Integration. Laut unserer Toolseite gibt es mehrere Pakete von Free bis Enterprise, konkrete Preise nur über den Preiskalkulator im Kundenportal. Früher veröffentlichte Richtwerte lagen bei rund 79 bis 179 € im Monat. Richtige Wahl, wenn du primär EUDAMED-Compliance effizient managen möchtest, ohne ERP-Integration. Deutschsprachiger Support, EU-Datenhaltung.

KUMAVISION medtec365 , wenn du gleichzeitig ERP modernisierst
ERP-Branchensoftware (Microsoft Dynamics 365 Business Central) mit vollständig integriertem UDI- und EUDAMED-Modul. Einmalige Datenpflege im ERP, automatischer XML-Export, integrierter Etikettendruck. Enterprise-Implementierung, kein öffentlicher Tarif, dazu laut Toolseite die Business-Central-Lizenz je Nutzer. Sinnvoll für Hersteller mit 100–500 Mitarbeitenden, die ihr ERP modernisieren und gleichzeitig EUDAMED abdecken wollen.

ChatGPT oder Claude , als Vorerfassungs- und Klassifizierungshilfe
Nicht als vollautomatisches Registrierungssystem, sondern für den Schritt davor: Produktbeschreibungen analysieren, fehlende EUDAMED-Felder identifizieren, EMDN-Codes vorschlagen (zur Verifikation), Vollständigkeitschecks gegen die EUDAMED-Feldliste. Kostenlos nutzbar für erste Tests mit öffentlichen Datenblättern, kein EUDAMED-spezifisches Modul, man baut die Logik durch Prompts selbst. Für unveröffentlichte technische Unterlagen einen Business- oder Team-Tarif nutzen.

Greenlight Guru , wenn du QMS und Produktregistrierung in einem System willst
Spezialisiertes eQMS für Medizinproduktehersteller mit integrierter Regulatory-Nachverfolgungsfunktion. Nicht primär auf EUDAMED-Bulk-Upload ausgerichtet, aber für Hersteller, die ihr gesamtes QMS digitalisieren und dabei auch Produktregistrierungen nachverfolgen wollen, die konsequenteste Lösung. Laut unserer Toolseite Einstieg ab rund 25.000 bis 35.000 USD/Jahr; ausschließlich englischsprachig, US-Hosting.

MasterControl , wenn ihr primär Life-Sciences-QMS-Anforderungen habt
Wie Greenlight Guru eine eQMS-Plattform, aber mit stärkerem Fokus auf GxP-konforme Validierung und breiterem Life-Sciences-Scope. Sinnvoll, wenn neben Medizinprodukten auch pharmazeutische Prozesse abgebildet werden sollen. Laut unserer Toolseite grob 25.000 bis 200.000 USD/Jahr, US-Hosting.

Zusammenfassung: Wann welcher Ansatz

• Kleines Portfolio (< 100 UDIs), schnell Compliance erreichen → mytracekey UDI Manager , kleines Paket
• Mittleres Portfolio (100–500 UDIs), EUDAMED-fokussiert → mytracekey UDI Manager , größeres Paket
• ERP-Modernisierung parallel zu EUDAMED → KUMAVISION medtec365
• Erste Validierungshilfe ohne Tool-Investment → ChatGPT oder Claude als Vorerfassungsassistent
• Vollständiges QMS plus Regulatory-Nachverfolgung → Greenlight Guru oder MasterControl

Datenschutz und Datenhaltung

EUDAMED-Daten sind per Definition öffentlich, die Datenbank ist darauf ausgelegt, dass Krankenhäuser, Behörden und die Öffentlichkeit Produktinformationen abrufen können. Die DSGVO-Frage stellt sich weniger für die EUDAMED-Daten selbst als für die Quelldaten, aus denen das System seine Informationen bezieht.

Wenn das Automatisierungssystem Zugriff auf technische Dokumentation, Risikoanalysen, Zertifikate und Produktspezifikationen braucht, gilt:

• KI-Tools wie ChatGPT oder Claude im Consumer-Einsatz verarbeiten hochgeladene Dokumente auf US-Servern. Wenn diese Dokumente Betriebsgeheimnisse enthalten, proprietäre Formulierungen, Produktionsparameter, unveröffentlichte technische Details, sollte das vor dem Einsatz mit dem Datenschutzbeauftragten besprochen werden. Alternativen: Azure OpenAI Service in der EU-Region (Frankfurt) oder selbst gehostete Modelle.
• Spezialisierte EUDAMED-Tools wie mytracekey UDI Manager verarbeiten Daten auf EU-Servern. Ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO muss abgeschlossen werden, bevor Produktdaten hochgeladen werden, bei mytracekey über das Kundenportal erhältlich.
• ERP-integrierte Lösungen wie KUMAVISION medtec365 laufen auf Microsoft Azure Infrastruktur, EU-Region verfügbar. Die DSGVO-Konformität ist für Microsoft Dynamics 365 durch ein EU-Standardvertragsklausel-Paket abgedeckt.

Die technische Dokumentation, die für EUDAMED benötigt wird, enthält in der Regel keine personenbezogenen Daten im Sinne der DSGVO, es geht um Produkteigenschaften, nicht um Patientendaten. Dennoch gilt: Interne Sicherheitsbewertungen, unveröffentlichte Risikoanalysen und Prüfberichte sind schützenswert aus Geschäftsgeheimnisperspektive. Wer diese Dokumente an KI-Dienste übergibt, sollte das bewusst entscheiden, und nur Business-, Team- oder API-Angebote nutzen, deren Bedingungen Vertraulichkeit zusichern und Training auf den Eingaben ausschließen.

Was es kostet, realistisch gerechnet

Einmalige Einrichtungskosten

• Datenmapping und -migration: 2–6 Wochen interner Aufwand für die RA/QM-Abteilung (Stunden sind der dominante Kostenfaktor)
• Externe Beratung für EUDAMED-Prozessaufbau: 3.000–12.000 €, je nach Portfolio-Komplexität und Systemintegration
• Tool-Setup: bei mytracekey UDI Manager minimal (SaaS, kein Installationsaufwand); bei KUMAVISION medtec365 erheblich (ERP-Implementierung)
• EUDAMED Playground nutzen: kostenlos; die EU-Kommission stellt eine Testumgebung bereit

Laufende Kosten (monatlich)

• mytracekey UDI Manager : aktuelle Preise über den Preiskalkulator, früher veröffentlichte Richtwerte 79–179 €/Monat je nach Portfoliogröße
• Claude als Vorerfassungsassistent für öffentliche Datenblätter: Pro für 20 €/Monat
• ChatGPT als Alternative: Plus für 23 €/Monat. Für unveröffentlichte Unterlagen jeweils Business oder Team, ab zwei Plätzen
• Greenlight Guru : laut Toolseite ab rund 25.000 bis 35.000 USD im Jahr
• MasterControl : laut Toolseite grob 25.000 bis 200.000 USD im Jahr
• Personalaufwand EUDAMED-Betreuung nach Automatisierung: ca. 2–4 Stunden/Monat statt 15–30 Stunden/Monat (Annahme)

Was du dagegen rechnen kannst
Ein Regulatory-Affairs-Spezialist, der 20 Stunden pro Monat mit EUDAMED-Datenpflege verbringt: Bei einem Bruttostundensatz von 30–45 €/Stunde sind das 600–900 €/Monat an direkten Personalkosten. Nach Automatisierung: 2–4 Stunden, also 60–180 €/Monat. Die Differenz von 540–720 €/Monat ist Arbeitszeit, kein Geld auf dem Konto, solange niemand weniger Stunden bezahlt bekommt. Sie liegt aber deutlich über den früheren Richtwerten der Tool-Lizenz von 79–179 € im Monat.

Das vorsichtige Szenario: Nur die Hälfte der Zeitersparnis wird realisiert, weil Datenpflege und Überprüfung mehr Zeit kosten als erwartet. Bei 30–45 € je Stunde decken dann schon 2 bis 4 gesparte Stunden im Monat eine Lizenz dieser Größenordnung.

Hinzu kommt der schwerer kalkulierbare Wert: Eine Markteinführungsverzögerung durch einen EUDAMED-Fehler kostet den Deckungsbeitrag der verlorenen Tage oder Wochen, nicht den Umsatz. Wie viel das ist, weißt nur du.

Wie du den Nutzen tatsächlich misst

• Anzahl der EUDAMED-Einreichungen pro Monat vs. Korrekturrunden: der direkte Effizienzindikator
• Durchschnittlicher Zeitaufwand pro neuem UDI-Eintrag: vorher messen, nachher vergleichen
• Anzahl der Pflichtfelder, die bei der initialen Datenextraktion fehlen: zeigt die Qualität der Quelldaten

Typische Einstiegsfehler

1. EUDAMED als „Einmalaufgabe” behandeln.
Viele Hersteller registrieren ihre Produkte einmalig und denken, das war’s. In Wirklichkeit verlangt die MDR (Anhang VI Teil C Abschnitt 5.8), dass Änderungen, für die keine neue UDI-DI nötig ist, innerhalb von 30 Tagen in der UDI-Datenbank aktualisiert werden, und Änderungen, die eine neue UDI-DI auslösen, brauchen einen neuen Eintrag vor dem Inverkehrbringen. Wer keine Prozesse etabliert, die Produktänderungen automatisch mit EUDAMED-Update-Pflichten verknüpfen, hat nach 18 Monaten einen Eintragsstau, und ein Audit-Risiko. Die Automatisierung des Änderungsmanagements ist technisch aufwendiger als die initiale Registrierung, aber mindestens genauso wichtig.

2. Mit Produkten starten, bevor die Akteur-Registrierung abgeschlossen ist.
Actor Registration und Device Registration sind sequenziell, ohne validierte SRN lässt EUDAMED keine Produkteinträge zu. Trotzdem investieren Hersteller wochenlang in die Produktdatenvorbereitung, bevor sie die SRN-Validierung angestoßen haben. Die SRN-Validierung kann 2–6 Wochen dauern, abhängig von der nationalen Behörde. Zuerst Actor Registration beantragen, dann Produktdaten vorbereiten.

3. Den EUDAMED Playground überspringen.
Die EU-Kommission stellt eine Testumgebung bereit, in der Hersteller XML-Dateien und manuelle Einträge gegen die Validierungsregeln testen können, ohne Auswirkungen auf die Produktionsdatenbank. Wer direkt in die Produktionsumgebung geht, lernt die EUDAMED-Validierungslogik auf die harte Tour: kryptische Fehlermeldungen, Zeitverlust, Frustration. Das gilt besonders für die dokumentierte Sequenzierungsabhängigkeit bei UDI-DI und Marktinformationen.

4. Das System einrichten und die Datenpflege vergessen.
Das ist der schleichende Fehler. Nach dem initialen Hype um EUDAMED-Compliance läuft das System, aber niemand pflegt die Quelldaten. Wenn drei Monate später eine Produktvariante zertifiziert wird und das ERP aktualisiert ist, aber niemand den EUDAMED-Update angestoßen hat, ist die Compliance weg, ohne dass es jemandem auffällt. EUDAMED prüft nicht aktiv, ob die Einträge noch aktuell sind. Das muss das interne Änderungsmanagement leisten.

Was mit der Einführung wirklich passiert, und was nicht

Die Automatisierung von EUDAMED-Prozessen trifft in vielen Unternehmen auf eine spezifische Konstellation: Regulatory-Affairs-Spezialistinnen und -Spezialisten, die EUDAMED bereits irgendwie beherrschen, mit Erfahrung, Routinen und einem Gespür für die Fehlerquellen. Diese Menschen haben selten den größten Leidensdruck. Den haben die Projektmanager, die Termine schieben, und die Geschäftsführung, die Markteinführungsrisiken managen.

Drei typische Muster in der Einführungsphase:

Die RA-Expertin, die das Neue nicht braucht.
Wer gelernt hat, in EUDAMED zu arbeiten, hat diese Kompetenz aufgebaut, und investiert. Ein System, das diese Arbeit übernimmt, kann sich anfühlen wie eine Entwertung dieser Investition. Konkrete Strategie: nicht ersetzen, sondern erweitern. „Das System übernimmt die Routinepflege. Du übernimmst die strategische Qualitätssicherung: du entscheidest, welche Vorerfassungsvorschläge korrekt sind und welche nicht.” Diese Botschaft muss vor dem ersten Demo-Tag klar sein, nicht danach.

Die IT, die EUDAMED für ein normales Integrationsprojekt hält.
EUDAMED hat eine ungewöhnliche API-Architektur und dokumentierte Validierungsabhängigkeiten, die in keiner Integrationsplattform als Standard-Connector verfügbar sind. Wer das unterschätzt, plant zu kurze Sprints und verspricht zu frühe Liefertermine. Besser: Mit XML-Bulk-Upload starten, M2M als separates Folgeprojekt planen, mit eigenem Budget und eigenem Zeitplan.

Das Management, das nach drei Monaten fragt, warum EUDAMED noch nicht „fertig” ist.
EUDAMED-Compliance ist kein abgeschlossenes Projekt, sondern ein laufender Prozess. Jede neue Produktvariante, jede Zertifikatserneuerung, jede Adressänderung erzeugt Aktualisierungspflichten. Das muss vor der Einführung kommuniziert werden, nicht als Warnung, sondern als realistisches Bild des Betriebs.

Was wirklich hilft: Einen 30-Tage-Pilot mit einem klar abgegrenzten Produktsegment (z. B. eine Produktfamilie mit 10–15 Konfigurationen) durchführen. Zeitmessung vorher und nachher. Fehlerrate dokumentieren. Erst dann auf das gesamte Portfolio ausweiten.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

„Wir haben so wenige Produkte, das lohnt sich nicht.”
Das stimmt, für sehr kleine Portfolios. Wer unter 50 Produktkonfigurationen hat und ein stabiles Sortiment ohne häufige Variantenerweiterungen, kommt mit manuellem Eintrag und einem XML-Export-Template aus. ACKOMAS nennt aus Erfahrung einen Kipppunkt um 200 UDI-DIs, warnt aber selbst davor, nur auf die Menge zu schauen: Häufige Änderungen sprechen schon deutlich darunter für ein Werkzeug.

„EUDAMED ändert sich doch laufend, bis das System konfiguriert ist, sind die Regeln wieder anders.”
Partiell berechtigt: EUDAMED hat seit 2020 mehrere Anpassungen erfahren. Aber der Kern der UDI-Registrierungsstruktur ist seit dem Basis-UDI-DI-Konzept stabil. Spezialisierte Tools wie mytracekey UDI Manager werden aktiv gepflegt und reagieren auf Regeländerungen mit Software-Updates, das ist ein Argument für SaaS-Tools statt selbstgebauter Lösung, kein Argument gegen Automatisierung generell.

„Wir haben das bisher immer manuell gemacht und hatten keine Probleme.”
Bisher. EUDAMED ist seit Mai 2026 Pflicht, und die Einträge sind öffentlich einsehbar, für Kunden, Wettbewerber und Behörden. Mit wachsendem Portfolio steigt die Zahl der Kopiervorgänge und damit die Gelegenheit für Fehler. Die Frage ist nicht ob, sondern wann der erste Korrekturdurchgang Kosten verursacht, die eine Tool-Lizenz für viele Monate gedeckt hätten.

Woran du merkst, dass das zu dir passt

• Dein Portfolio hat 50 oder mehr aktive Produktkonfigurationen, und mit jeder Produkteinführung kommen neue hinzu
• EUDAMED-Einträge gehören zur Aufgabenliste einer Fachkraft mit anderen Kernaufgaben, und die Person verbringt mehr Zeit damit, als alle anderen im Unternehmen wissen
• Du hattest mindestens einmal eine Markteinführungsverzögerung oder einen Kundenstau, weil EUDAMED-Daten fehlten oder fehlerhaft waren
• Dein Produktportfolio wächst, neue Varianten, neue Märkte, neue Zertifizierungszyklen, und der EUDAMED-Aufwand wächst proportional mit
• Ihr arbeitet gerade an MDR-Compliance und EUDAMED ist Teil eines größeren Regulatory-Affairs-Digitalisierungsprojekts, ähnlich wie bei der Lieferantenqualifikation nach MDR

Wann das noch nicht das Richtige ist, drei harte Ausschlusskriterien:

1. Weniger als 50 Produktkonfigurationen, kein starkes Portfoliowachstum geplant. Der Einrichtungsaufwand für ein Automatisierungssystem übersteigt den Nutzen. Ein sauber geführtes Excel-Template für den XML-Export reicht aus, und ein externer EUDAMED-Dienstleister kann die initiale Registrierung übernehmen, Angebote vergleichen.

2. Produktdaten liegen nicht strukturiert vor. Wenn Artikel-Stammdaten über mehrere ERP-Systeme, viele Excel-Sheets und Papierakten verteilt sind, ohne konsistentes Feldsystem, kann KI keine zuverlässigen EUDAMED-Daten extrahieren. Zuerst eine Single Source of Truth für Produktdaten schaffen, ERP-Konsolidierung oder zumindest ein strukturiertes Produktdaten-Repository. Dann Automatisierung.

3. Keine Person mit EUDAMED-Verantwortung im Haus. Ein automatisiertes System reduziert Aufwand, ersetzt aber keine inhaltliche Verantwortung. Wer EUDAMED-Einträge ohne jemanden betreibt, der Validierungsregeln, Klassifizierungsfragen und MDR-Interpretation kennt, produziert fehlerhafte Einträge, nur schneller. Ohne eine Person mit RA-Kompetenz, die dafür fest Zeit hat, in der Einführung deutlich mehr als die 2–4 Stunden im Monat des Regelbetriebs, ist das Automatisierungsprojekt zum Scheitern verurteilt.

Das kannst du heute noch tun

Öffne die öffentliche EUDAMED-Suche der Europäischen Kommission, kostenlos, kein Account nötig. Die Testumgebung (Playground) enthält Testdaten, echte Einträge findest du nur in der öffentlichen Datenbank. Suche nach einem Produkt eines Mitbewerbers und schau dir die Eintragsstruktur an: Welche Felder sind befüllt, wie ist die Basis-UDI-DI-Struktur aufgebaut? Das gibt dir ein reales Bild davon, was EUDAMED von dir erwartet, ohne dass du selbst etwas einreichen musst.

Für den nächsten Schritt: Nimm ein veröffentlichtes Datenblatt eines deiner Geräte und lass es von ChatGPT oder Claude analysieren. Unveröffentlichte technische Unterlagen gehören in einen Business- oder Team-Tarif, nicht ins private Abo. Dazu kannst du folgenden Prompt verwenden:

Das Ergebnis zeigt dir in 10 Minuten zwei Dinge: Welche Felder in deiner Produktdokumentation gut strukturiert vorliegen, und welche du vor der EUDAMED-Einreichung noch klären musst. Das ist kein Ersatz für die eigentliche Registrierung, aber ein ehrlicher Vorher-Check für die Datenbasis.

Quellen & Methodik

• tracekey solutions GmbH: Costs of a EUDAMED Solution (2024). Pricing für den mytracekey UDI Manager und Kalkulation des manuellen Aufwands (15 Min./UDI bei 25 €/Std.). Tracekey ist ein spezialisierter EUDAMED-Dienstleister mit öffentlicher Preisübersicht. Quelle: tracekey.com/en/costs-of-a-eudamed-solution/ (abgerufen April 2026)
• ACKOMAS: Manual Entry or Automation, Which Approach Is Right for Registering Your Devices in EUDAMED? (Leitfaden, 15.09.2025). Nennt aus Erfahrung einen Kipppunkt um 200 UDI-DIs und betont, dass die Menge allein irreführt. Quelle: ackomas.com/guide/manual-entry-or-automation (abgerufen am 19.09.2026)
• europe-it-consulting.ch: EUDAMED Data Management (17.02.2026). Dokumentiert die technische Race-Condition-Abhängigkeit zwischen UDI-DI-Stammdaten und Marktinformations-Snapshot in der EUDAMED-Validierungspipeline. Quelle: europe-it-consulting.ch/eudamed-data-management (abgerufen April 2026)
• KUMAVISION AG: Zukunftssicheres UDI-Management durch digitale Produktregistrierung in EUDAMED (2025). Beschreibt die Integration von UDI/EUDAMED-Prozessen in ERP-Software auf Basis von Microsoft Dynamics 365. Quelle: kumavision.com/blog/udi-management-mit-medtec365 (abgerufen April 2026)
• Yu, Weile, Courtot: Benchmarking LLM-based Information Extraction Tools for Medical Documents (Preprint, medRxiv, 22.01.2026). Nicht begutachtet. Extraktion aus 1.000 fiktiven medizinischen Dokumenten, bestes Modell GPT-4.1-mini mit durchschnittlichem F1-Wert 55,6. Keine Studie zu Produktattributen, nur als Anhaltspunkt zitiert. Quelle: medrxiv.org/content/10.64898/2026.01.19.26344287v1 (abgerufen am 19.09.2026)
• Beschluss (EU) 2025/2371 der Kommission vom 26. November 2025, veröffentlicht am 27.11.2025: Funktionsfähigkeit der Module Akteur-Registrierung, UDI-Datenbank und Produktregistrierung, Benannte Stellen und Bescheinigungen, Marktüberwachung (eur-lex.europa.eu, abgerufen am 19.09.2026).
• MDR Art. 27, 29, Art. 123 Abs. 3 Buchst. d und e, Anhang VI Teil C Abschnitt 5.8: Verordnung (EU) 2017/745, konsolidierte Fassung vom 19.07.2026 (eur-lex.europa.eu, abgerufen am 19.09.2026): UDI-Zuteilung, Registrierung vor dem Inverkehrbringen, Geltungsbeginn sechs Monate nach der Mitteilung, zwölf Monate für Bestandsprodukte, 30-Tage-Frist für Aktualisierungen ohne neue UDI-DI.
• MDCG 2018-1 rev. 4 (April 2021): Guidance on basic UDI-DI and changes to UDI-DI.

Du willst wissen, welche EUDAMED-Felder in eurem Portfolio strukturiert vorliegen und wo die größten Lücken sind? Meld dich, das klären wir gemeinsam in einem kurzen Gespräch.