EUDAMED Datenaustausch
EUDAMED bietet drei grundsätzlich unterschiedliche Wege für die Übermittlung von Daten: manuelle Eingabe über die Benutzeroberfläche, XML-Upload und automatisierten Machine-to-Machine-Datenaustausch. Die technisch anspruchsvollste Variante ist nicht automatisch die beste.
EUDAMED & UDI bei AENUMA · UDI im ERP · EUDAMED Datenpflege
| Variante | Automatisierung | Typischer Einsatz |
|---|---|---|
| EUDAMED User Interface | manuell | Kleine Portfolios, geringe Änderungsfrequenz |
| XML Upload / Download | teilautomatisiert | Mittlere Datenmengen, strukturierte interne Daten |
| Machine-to-Machine (M2M) | automatisiert | Große Portfolios, viele Änderungen, systematischer Datenaustausch |
Die Europäische Kommission weist selbst darauf hin, dass die wirtschaftlich sinnvollste Lösung von mehreren Parametern abhängt. Datenvolumen und Übertragungsfrequenz sind wichtig, aber auch Systemreife, Interoperabilität, Sicherheit und Betriebsaufwand.
Die einfachste technische Variante ist die direkte Pflege im EUDAMED User Interface. Mitarbeitende übertragen freigegebene Daten aus internen Quellen in die Anwendung.
Das kann für Hersteller mit einem überschaubaren Portfolio durchaus sinnvoll sein. Eine Schnittstelle erzeugt Entwicklungs-, Test- und Betriebsaufwand. Wenn nur wenige Produktdatensätze existieren und Änderungen selten sind, kann ein kontrollierter manueller Prozess wirtschaftlicher sein.
Das Problem entsteht nicht durch die manuelle Eingabe selbst, sondern durch fehlende Governance. Wenn Daten erst beim Öffnen von EUDAMED aus verschiedenen Excel-Dateien zusammengesucht werden, ist der Prozess nicht wirklich kontrolliert. Auch bei manueller Übertragung sollte vorher eine freigegebene Datenquelle existieren.
Der XML-Ansatz ist teilautomatisiert. Daten können intern strukturiert erzeugt und gegen die von EUDAMED bereitgestellten XSD-Schemata validiert werden. Der eigentliche Upload beziehungsweise Download bleibt jedoch ein manueller Schritt.
Für viele mittelständische Hersteller kann diese Variante ein sinnvoller Zwischenweg sein: Das interne System erzeugt einen definierten Datensatz, technische Validierungen werden automatisiert, aber es ist keine vollständige M2M-Infrastruktur erforderlich.
Der größte Vorteil ist die Trennung zwischen Datenaufbereitung und Portalbedienung. Statt Felder einzeln einzutragen, kann ein konsistenter Datensatz aus dem Product Master oder Regulatory-System erzeugt werden.
Der Nachteil: Der Prozess benötigt weiterhin einen kontrollierten manuellen Übergabeschritt und einen Mechanismus für Rückmeldungen und Fehler. Ein abgewiesener XML-Datensatz muss eindeutig zur internen Quelle zurückgeführt und korrigiert werden können.
Beim M2M-Datenaustausch kommuniziert ein externes Backend automatisiert mit den EUDAMED-Backend-Services. Die Daten werden ebenfalls im von EUDAMED erwarteten XML-Format ausgetauscht, jedoch ohne den manuellen Upload über die Benutzeroberfläche.
Technisch ist dafür mehr nötig als eine einfache REST-API. Die aktuelle EUDAMED-Dokumentation beschreibt einen AS4-konformen eDelivery Access Point und eine sichere Kommunikationsstruktur zwischen Organisation und EUDAMED. Auf EUDAMED-Seite wird Domibus eingesetzt.
Zum technischen Onboarding gehören verschiedene Dokumente und Voraussetzungen. Die EU-Dokumentation nennt unter anderem XSDs, XML-Beispiele, Service Definitionen, Business Rules, Data Dictionaries sowie Unterlagen für Third-Party-Vereinbarungen, Business Justification und technisches Onboarding.
Die Frage lässt sich nicht mit einer festen Anzahl von Produkten beantworten. Entscheidend ist die Kombination aus Volumen und Dynamik.
Ein Unternehmen mit 2.000 Produkten, die sich kaum ändern, hat einen anderen Business Case als ein Hersteller mit 300 Produkten, aber vielen Varianten, Verpackungsänderungen und regelmäßigen regulatorischen Updates.
Für die Entscheidung sollten mindestens diese Faktoren bewertet werden:
Eine EUDAMED-Schnittstelle sollte nicht der Ort sein, an dem Datenprobleme gelöst werden. Sie sollte freigegebene Daten transportieren.
Wenn Basic UDI-DI, UDI-DI, Produktname, Risikoklasse, Verpackungshierarchie und regulatorische Attribute aus verschiedenen Quellen kommen und niemand die führende Quelle benennen kann, wird M2M das Problem nicht beseitigen. Es macht lediglich die Übertragung schneller.
Vor der Integrationsentscheidung sollten deshalb drei Dinge stehen: ein eindeutiges Datenmodell, definierte Owner und ein kontrollierter Freigabeprozess.
Grundlage: Basic UDI-DI vs. UDI-DI
In einer Microsoft-Landschaft kann der operative Produktstamm in Dynamics 365 geführt werden, während regulatorische Attribute in Dataverse oder einer spezialisierten Regulatory-Anwendung liegen. Power Platform kann Prüf- und Freigabeprozesse unterstützen. Eine Integrationsschicht erzeugt daraus den EUDAMED-konformen Datensatz.
Wichtig ist dabei die Richtung des Designs: Nicht „Wie verbinden wir Dynamics 365 schnell mit EUDAMED?“, sondern „Welche freigegebenen Daten müssen aus welchen führenden Quellen an EUDAMED übertragen werden?“
| Ebene | Aufgabe |
|---|---|
| Dynamics 365 / ERP | Operative Artikel-, Varianten-, Verpackungs- und Prozessdaten |
| Dataverse / Regulatory Data | Regulatorische Attribute, UDI-Struktur, fachliche Ownership |
| Workflow | Prüfung, Freigabe, Change Control |
| Integration | Transformation, Validierung, Übertragung und Rückmeldung |
| EUDAMED | Regulatorisches Zielsystem |
Eine Integration ist erst vollständig, wenn auch der Fehlerfall gestaltet ist. EUDAMED kann Daten aufgrund technischer oder fachlicher Regeln zurückweisen. Diese Rückmeldung muss einem konkreten Produktdatensatz zugeordnet werden und einen kontrollierten Korrekturprozess auslösen.
Ein belastbarer Prozess dokumentiert deshalb nicht nur „gesendet“, sondern mindestens: erstellt, intern validiert, freigegeben, übertragen, technisch bestätigt, fachlich akzeptiert oder abgewiesen.
UI ist sinnvoll, wenn Datenvolumen und Änderungsfrequenz niedrig sind und ein klarer manueller Kontrollprozess wirtschaftlich bleibt.
XML ist sinnvoll, wenn Daten intern bereits strukturiert vorliegen und manuelle Feldeingabe vermieden werden soll, aber ein vollständiger M2M-Betrieb noch keinen Business Case hat.
M2M ist sinnvoll, wenn Volumen, Änderungsfrequenz und Prozesskritikalität eine automatische Übertragung rechtfertigen und das Unternehmen die notwendige Daten- und Integrationsreife besitzt.
Hat EUDAMED eine einfache API?
Der offizielle M2M-Datenaustausch ist umfangreicher als ein typischer REST-API-Aufruf. EUDAMED beschreibt dafür eine eigene DTX-Architektur mit XML, AS4-konformem Access Point und eDelivery-Komponenten.
Kann XML automatisch erzeugt werden?
Ja. Die Dateien können aus internen Systemen erzeugt und gegen die EUDAMED-Schemata validiert werden. Beim XML-Upload bleibt die eigentliche Übertragung jedoch manuell.
Braucht jeder Hersteller M2M?
Nein. Die EU weist ausdrücklich darauf hin, dass eine vollautomatische Verbindung bei geringem Volumen oder geringer Übertragungsfrequenz wirtschaftlich unverhältnismäßig sein kann.
Kann ein externer Anbieter den Access Point betreiben?
Die technische Dokumentation sieht auch Third-Party-Konstellationen vor und stellt dafür entsprechende Vereinbarungsunterlagen bereit. Governance und Datenverantwortung des Herstellers bleiben trotzdem relevant.
Die Entscheidung für UI, XML oder M2M sollte erst nach einer Daten- und Prozessanalyse fallen. Wer zuerst die Schnittstelle auswählt und danach das Datenmodell klärt, dreht die Reihenfolge um.
Nächster Schritt: EUDAMED-Readiness-Check oder EUDAMED- und UDI-Daten im System.
Weiterlesen: EUDAMED-Bestandsprodukte 2026
Weiterlesen: UDI im ERP
Weitere Beiträge zu EUDAMED und Datenübertragung
EUDAMED Information Centre: Guidelines on Data Exchange
EUDAMED Information Centre: M2M Data Exchange Architecture
EUDAMED Information Centre: Technical Documentation
Stand: 17. August 2026. Organisatorische und technische Einordnung, keine rechtliche Einzelfallprüfung.
