Die EUDEMED ist die europäische Datenbank für Medizinprodukte nicht nur zur Verwaltung von Medizinprodukten.
Die Medizinprodukteverordnung (MDR) setzt auf die EUDAMED und legt fest, welche Anforderungen in dieser Datenbank gespeichert werden müssen.
Diese Vorschriften betreffen die Arbeit von Herstellern ebenso wie von Behörden und benannten Stellen.
1. Welchen Zweck die EU mit der EUDAMED verfolgt
Die EUDEMED geht auf einen Beschluss der EU-Kommission (2010/227/EU) zurück. Darin formuliert die EU den Zweck der Eudamed:
„Die Europäische Datenbank für Medizinprodukte soll die Marktüberwachung verbessern, indem den zuständigen Behörden ein rascher Zugriff auf Informationen über die Hersteller und ihre Bevollmächtigten, über Produkte und Bescheinigungen sowie auf Vigilanzdaten gewährt wird; ferner soll sie zum Austausch von Informationen über klinische Prüfungsdaten sowie zur einheitlichen Anwendung der oben genannten Richtlinien, insbesondere hinsichtlich der Meldevorschriften, beitragen.“
Dieser Beschluss aus dem April 2010 erfolgte zeitgleich mit dem Verbot der Brustimplantate des Herstellers PIP (mehr zum PIP-Skandal).
2. Regulatorische Anforderungen
Die Medical Device Regulation MDR verpflichtet die Hersteller die Daten über sich und über ihre Produkte in der EUDAMED zu speichern:
- Artikel 31 (1): „Bevor sie [Hersteller, Bevollmächtigte, Importeure] ein Produkt […] in Verkehr bringen, geben [sie] die Angaben gemäß Anhang VI Teil A Abschnitt 1 in das in Artikel 30 genannte elektronische System ein, um sich registrieren zu lassen, sofern sie sich nicht bereits gemäß diesem Artikel registriert haben. […]“
- Artikel 29 (4): „Bevor ein Produkt […] in Verkehr gebracht wird, gibt der Hersteller die in Anhang VI Teil A Abschnitt 2 — mit Ausnahme von Abschnitt 2.2 — genannten Angaben in Eudamed ein oder prüft diese, wenn sie bereits eingegeben sind, nach; danach hält er diese Informationen auf dem neuesten Stand.“
Für Klasse III Produkte und Implantate verlangt Artikel 32 zusätzlich eine Zusammenfassung der Sicherheit und Leistungsfähigkeit bei EUDAMED einzustellen. Die Datenbank soll auch für die Öffentlichkeit (teilweise) einsehbar sein.
3. In der EUDAMED gespeicherte Daten
Welche Daten die EUDAMED abspeichern muss legt ebenfalls der o.g. EU-Beschluss fest:
a) Akteur (Hersteller, Bevollmächtigter)
- Kennung (mehr dazu weiter unten)
- Name
- Straße
- Ort
- Postleitzahl
- Land
- Telefonnummer oder E-Mail-Adresse
b) Produkt
- Produkt-Code
- Produktbezeichnung/-fabrikat
- Die MDR fordert gemäß Artikel 24 und gemäß Anhang V Part A, Sektion 2 zusätzlich UDI, Risikoklasse, wiederverwendbares Produkt (j/n), mit tierischem oder menschlichem Gewebe (j/n) usw.
c) Bescheinigung
- Nummer der Bescheinigung
- Art der Bescheinigung
- Ausstellungsdatum
- Ende der Gültigkeit
- Hersteller und gegebenenfalls Bevollmächtigter (siehe Felder unter „Akteur“)
- Benannte Stelle (aus dem System ausgewählt)
- Allgemeine Beschreibung der Gültigkeit und gegebenenfalls Einzelheiten zum Produkt (siehe Felder unter Punkt „Produkt“)
- Status und gegebenenfalls Gründe für die Entscheidung der benannten Stelle
d) Vorkommnis
- Aktenzeichen der zuständigen Behörde
- Hersteller und gegebenenfalls Bevollmächtigter (siehe Felder unter „Akteur“)
- Kontaktangaben zum Hersteller
- Aktenzeichen des Herstellers/Nummer der sicherheitsrelevanten korrektiven Maßnahmen im Feld (Field Safety Corrective Action, FSCA)
- Produkt (siehe Felder unter Punkt „Produkt“), sowie gegebenenfalls Losnummer, Seriennummer, Softwareversion;
- Benannte Stelle (aus dem System ausgewählt)
- Markt, auf dem das Produkt in Verkehr gebracht wird;
- Vertraulich
- Vollständige Untersuchung
- Hintergrundinformation (Beschreibung)
- Schlussfolgerung
- Empfehlung
- Maßnahmen und Maßnahmenbeschreibung.
e) Klinische Prüfung
- Hersteller und gegebenenfalls Bevollmächtigter (siehe Felder unter Punkt „Akteur“)
- Produkt (siehe Felder unter Punkt „Produkt“)
- Bezeichnung der Prüfung
- Protokollnummer
- Hauptziel
- Kontaktpersonen für die klinische Prüfung bei der zuständigen Behörde
- Von der zuständigen Behörde getroffene Entscheidungen
- Datum der Entscheidung und Gründe
- Vorzeitige Beendigung aus Sicherheitsgründen
- Datum der Entscheidung und Gründe.
Übrigens: Der englische Text spricht tatsächlich von „databank“ und nicht von „database“.
Die EUDAMED speichert weit mehr als nur die UDIs4. Identifikation der Hersteller
a) Registrierung der Hersteller und „Single Registration Number“ (SRN)
Genauso wie die Produkte in der EUDAMED über die UDI-DI eindeutig identifiziert werden müssen, müssen auch die Hersteller eindeutig identifizierbar sein. Das gilt auch für die anderen Wirtschaftsakteure wie die Importeure und EU-Repräsentanten mit Ausnahme der Händler.
Diese eindeutige Identifikation ist die „Single Registration Number“ (SRN), die die Behörden für die genannten Wirtschaftsakteur vergeben. Auch die Sponsoren der klinischen Prüfungen benötigen eine SRN.
Bisher scheinen die Behörden noch nicht in der Lage zu sein, die SRNs zu vergeben. Sollten Hersteller dennoch ihre Single Registration Number schon jetzt beantragen?
Dafür würde sprechen, dass man als Hersteller damit signalisiert, bereit zu sein, und damit vermeidet, dass man den schwarzen Peter zugeschoben bekommt. Anderseits verweist das BfArM auf seiner Seite daraufhin, dass die Frage, wie die SRN vergeben wird, derzeit noch in Klärung sei und die EUDAMED erste ab Mai 2022 verfügbar sei.
Das BfArM meint, die Hersteller hätte noch Zeit (Quelle)Doch ist das zutreffend? Die Planung, dass man die Module alle gleichzeitig ab Mai 2022 freischaltet, hat die EU im Juni 2020 wieder verworfen. Das „Actors Module“ soll wahrscheinlich als erstes freigeschaltet werden. Genau dieses bedarf der SRN…
b) Pflege der Daten und „Local User Administrator“ LUA
Die Hersteller sind verpflichtet, die Daten in der EUDAMED aktuell zu halten. Dazu müssen Sie einen „Local User Administrator“ benennen. Dieser LUA wiederum verwaltet die Berechtigungen für die vom Hersteller vorgesehenen Personen.
Es ist möglich, dass ein Hersteller seinen Importeur oder seinen EU-Repräsentanten als LUA berechtigt.
Noch ist nicht ganz klar, wie die LUA authentifiziert werden. Möglicherweise geschieht das über die nationalen (Aufsichts-)Behörden.
c) Vergabe von SRNs
Es kann aber sein, dass eine Firma mehrere SRNs erhält. Dies ist der Fall, wenn die Firma mehrere Rollen hat, beispielsweise als Hersteller eines Produkts und als Importeur eines anderen Produkts von einer anderen Firma. Auch die Rolle als EU-Repräsentant führt zu einer eigenen SRN. Umgekehrt hätte ein EU-Repräsentant, der mehrere Firmen vertritt, nur eine SRN, da er in der gleichen Rolle bleibt.
d) Sonderfall „klinische Prüfungen“
Die klinischen Prüfungen stellen einen Sonderfall dar. Das liegt daran, dass die Produkte noch über kein CE-Zeichen verfügen und daher noch gar nicht in der EUDAMED registriert sein müssten bzw. sein könnten.
Weil die EU-Kommission diese klinischen Prüfungen explizit auch erfassen will, gibt es ein eigenes Modul. Die Sponsoren – das sind i.d.R. die Hersteller – müssen sich darin registrieren und benötigen dazu ebenfalls eine SRN. Eine Ausnahme liegt vor, wenn die Prüfungen außerhalb Europas durchgeführt werden. Umgekehrt müssen die Hersteller auch Studien mit CE-gekennzeichneten Produkten erfassen, wenn diese „invasiv oder belastend“ sind (s. Artikel 74). Diese Prüfungen nennt man auch „Post-Market Clinical-Follow-up“ (PMCF) Prüfungen.
Die Hersteller dürfen ihre CROs (Clinical Research Organizations) autorisieren, die Daten in der EUDAMED zu pflegen.
5. Schnittstellen der EUDAMED
Die EUDAMED verfügt
- über die Möglichkeit einer Online-Eingabe (für Menschen) und
- über eine Schnittstelle, die den Upload von XML-Dateien erlaubt.
Sogar das Protokoll (https) legt die EU fest. Allerdings sind die XML-Schnittstellen nur teilweise spezifiziert (s.u.).
Als Favoriten für die Kodierung der Produkte zählen Klassifikationen der WHO, SNOMED, GMDN sowie ein italienisches System. Die Verhandlungen sollen im Januar 2019 zu einem Ergebnis sprich einer Entscheidung kommen. Bei GMDN, Global Medical Device Nomenclature, handelt es sich um die globale Nomenklatur für Medizinprodukte gemäß EN ISO 15225:2000.
Willkommen im letzten Jahrtausend
Als Entwickler wird man sich fragen:
- Weshalb nutzt man im 21. Jahrhundert noch einen Datei-Upload? Schon mal was von REST gehört?
- Weshalb spezifiziert die EU Technologien?
- Wenn Sie das tut, weshalb dann nur halb? Ohne die Angabe einer Schema-Datei ist die Forderung nach einer XML-Schnittstelle wertfrei.
- Sind Felder wie „Hauptziel“, „Markt, auf dem das Produkt in Verkehr gebracht werden soll“ wirklich Freitextfelder?
6. Zeitplan
a) Status quo
Die EU hat Ende 2019 bekannt gegeben, dass die EUDAMED nicht (wie ursprünglich geplant) modulweise freigegeben werden soll, sondern in einem Schuss. Damit verschiebt sich die Einführung auf 2022! Die EU-Kommission schreibt jetzt auf ihrer Webseite:
The Commission, in agreement with the Medical Device Coordination Group (MDCG), is going to make available the different modules on a gradual basis as soon as they are functional
Webseite der EU
Damit können sich Hersteller nicht mehr zurücklehnen: Zwar übernimmt das DIMDI noch die Eintragungen in die bisherige Form der EUDAMED und überträgt nach eigener Aussage alle zwei Wochen die Daten dorthin; d.h. nur die nationalen Behörden können und müssen (z.B. gemäß Artikel 14a, MDD) die EUDAMED nutzen (seit Mai 2011). Aber der nächste Schritt steht an:
The module on Actor registration will be the first module made available. Deployment of the module takes place at the latest by March 2021
Webseite der EU
Bis dahin melden Hersteller Produkte weiter über das DIMDI an, Zwischenfälle sind an das BfArM zu melden.
Die EU-Kommission hat inzwischen die Nomenklatur für Medizinprodukte festgelegt. Die Produkte sollen mit Hilfe dieser Produkt-Codes in de EUDAMED erfasst werden.
b) Rückblick
Klarstellung der MDCT zu Übergangsfristen (April 2019)
Im April 2019 hatte die MDCG eine Klarstellung veröffentlicht, die die Interpretation des missverständlichen Artikels 123 enthält:
the obligation for registration in EUDAMED of device data elements listed in both part A, Section 2, and Part B of Annex VI, shall be applicable as from the timelines indicated in Article 123(3)(e) (meaning from 18 months after the general application date or, if EUDAMED is not fully functional on time, from 24 months after the date of publication of the notice referred to in Article 34(3)).
MDCG
Die MDCG macht aber auch klar, dass die Pflicht der Hersteller, die UDI zu vergeben, davon unberührt bleibt.
Stand von Entwicklung und Testing (Sommer 2019)
Die ersten Module der EUDAMED sind bereits entwickelt. Die Entwickler (und die EU) gingen davon aus, dass die EUDAMED pünktlich zum 26. März(!) 2020 live gehen wird. Auch weil das gleiche Team vor drei Jahren die Kosmetika-Datenbank implementierte und sogar zwei Monate vor dem Zieldatum fertig war, herrscht Zuversicht.
Alle Pflichtmodule – dazu zählt auch das Vigilanz-Modul – sollten verfügbar sein. Erste Tests wie der des „Actors Modules“ liefen bereits erfolgreich. Beta-Tests liefen ebenfalls, an denen sich die Hersteller beteiligen können. Besonders Hersteller mit vielen Daten waren für die „Mass Upload Tests“ gesucht, die im Januar 2020 durchgeführt werden sollten.
Das war etwas überraschend, da das Format für den „Mass-Upload“ (der Produktdaten) noch unbekannt ist. Hingegen wurde die XML-Schnittstelle ist für das Vigilanz-Modul bereits spezifiziert.
So lange jedoch das Kodiersystem für die Produkt-Codes nicht feststeht, kann man die Tests nicht abschließen.
Eingabe von SRNs und LUAs
Ab dem 26.03.2020 sollten die SRNs und LUAs in der EUDAMED registriert werden. Ab dem 26. Mai 2020 mussten die Hersteller (und anderen Wirtschaftsakteure) die Daten eingeben. Doch das ist alles Makulatur.
Der Gesetzgeber gewährte eine Übergangsfrist von 18 Monaten. In dieser Zeit hätten die Hersteller alle Daten von allen Produkten (auch die noch unter der MDD in Verkehr gebracht wurden) erfasst haben. Ob es eine neue Übergangsfrist für diese Nummer gibt, ist derzeit unklar.
Die MDCG hat im April f2019 estgestellt, dass die Legacy-Produkte zwar auch in der EUDAMED eingegeben werden, dass die UDI-Pflichten aber nicht gelten. Weil die Basis-UDI-DI bzw. UDI-DI aber die Schlüssel in der Datenbank bilden, müsste die EUDAMED geändert werden.
the MDCG considers it appropriate to adapt the Eudamed design to allow the registration of legacy devices in Eudamed in the absence of a (Basic) UDI-DI.
MDCG 2019-05
GMDN Code (April 2019)
Die GMDN Codes werden ab dem 01.04.2019 kostenfrei für den Einsatz in der EUDAMED zur Verfügung stehen.
7. Fazit
Das EUDAMED-Projekt lief technisch bisher besser als viele Unkenrufe dies prognostizierten. Dennoch wäre der Umstieg für alle Beteiligten eine Herkulesaufgabe gewesen. Doch das ist alles hinfällig. Dieses Mal hat die Politik mit Ihrer Umentscheidung, die EUDAMED nur mit kompletter Funktionalität an den Start zu bringen, alle Zeitpläne obsolet gemacht.
Zugegeben, es gab Herausforderungen v.a. für Hersteller mit vielen Produkten, da der „Mass Upload“ weder spezifiziert noch implementiert oder gar getestet war. Hunderte oder Tausende Produkte über ein Web-Interface zu verwalten, ist kaum möglich.
Derzeit können Sie als Hersteller nicht viel tun, was die EUDAMED betrifft. Allerdings sollten Sie keinesfalls mit Ihren Vorbereitungen zur UDI zögern. Dort wartet viel Arbeit!
