Beschluss 2008/616/JI des Rates vom 23. Juni 2008 zur Durchführung des Beschlusses 2008/615/JI zur Vertiefung der grenzüberschreitenden Zusammenarbeit, insbesondere zur Bekämpfung des Terrorismus und der grenzüberschreitenden Kriminalität

Durchsuchbarer Text in vereinfachter Darstellung. Tabellen, Abbildungen und verbindliche Gestaltung bitte anhand der Originaldateien prüfen.

nwendung unterstützt. Durch eine Administratorfunktion kann der nationale Administrator entscheiden, welche Nachrichten protokolliert werden, z. B. Anfragen von Endnutzern, aus anderen Mitgliedstaaten eingehende Anfragen, aus den nationalen Registern bereitgestellte Angaben usw. Die Anwendung kann so konfiguriert werden, dass für die Protokollierung entweder eine interne oder eine externe (Oracle) Datenbank zum Einsatz kommt. Die Entscheidung darüber, welche Nachrichten protokolliert werden sollen, hängt eindeutig davon ab, welche Protokollierungsmöglichkeiten es sonst noch in den Legacy-Systemen und den angeschlossenen Client-Anwendungen gibt. Im Kopf jeder Nachricht sind der anfragende Mitgliedstaat, die anfragende Stelle in diesem Mitgliedstaat und der betreffende Nutzer sowie der Grund der Anfrage anzugeben. Durch die kombinierte Protokollierung im anfragenden und im antwortenden Mitgliedstaat ist eine vollständige Nachvollziehbarkeit jedes Nachrichtenaustauschs (z. B. auf Antrag eines betroffenen Bürgers) möglich. Die Protokollierung wird über das Eucaris-Web-Client (Menu Administration, Logging configuration) konfiguriert. Die Protokollierfunktionalität wird vom Kernsystem bereitgestellt. Ist die Protokollierung aktiviert, so wird die komplette Nachricht (Kopf und Text) in einem Protokollarchiv gespeichert. Die Protokollierungsebene kann je nach vordefiniertem Dienst und Art der Nachricht, die das Kernsystem durchläuft, gewählt werden. Protokollierungsebenen Folgende Protokollierungsebenen sind möglich: Privat — Nachricht wird protokolliert: Die Protokollierung ist NICHT vom Auszugsprotokolldienst (extract logging service) abrufbar, sondern nur auf nationaler Ebene für Audits und die Behebung von Problemen verwendbar. Keine — Nachricht wird in keinem Fall protokolliert. Arten von Nachrichten Der Informationsaustausch zwischen Mitgliedstaaten beinhaltet verschiedene Nachrichten, die in der nachstehenden Abbildung schematisch dargestellt sind. Folgende Nachrichtenarten (in der Abbildung beziehen sie sich auf das Eucaris-Kernsystem eines Mitgliedstaats X) sind möglich: 1. Request to Core System_Request message by Client 2. Request to Other Member State_Request message by Core System of this Member State 3. Request to Core System of this Member State_Request message by Core System of other Member State 4. Request to Legacy Register_Request message by Core System 5. Request to Core System_Request message by Legacy Register 6. Response from Core System_Request message by Client 7. Response from Other Member State_Request message by Core System of this Member State 8. Response from Core System of this Member State_Request message by other Member State 9. Response from Legacy Register_Request message by Core System 10. Response from Core System_Request message by Legacy Register Folgende Varianten des Informationsaustauschs sind in der Abbildung dargestellt: — Auskunftsersuchen von Mitgliedstaat X an Mitgliedstaat Y — blaue Pfeile. Abruf und Rückmeldung bestehen aus dem Nachrichtentyp 1, 2, 7 bzw. 6. — Auskunftsersuchen von Mitgliedstaat Z an Mitgliedstaat X — rote Pfeile. Abruf und Rückmeldung bestehen aus dem Nachrichtentyp 3, 4, 9 bzw. 8. — Auskunftsersuchen vom Legacy-Register an sein Kernsystem (diese Kommunikation bezieht auch Anfragen von Custom-Clients hinter dem Legacy-Register mit ein) — grüne Pfeile. Diese Anfragekategorie setzt sich aus den Nachrichtentypen 5 und 10 zusammen. Abbildung: Nachrichtentypen für die Protokollierung 2.3.4. Hardware-Sicherheitsmodul Ein Hardware-Sicherheitsmodul kommt nicht zum Einsatz. Hardware-Sicherheitsmodule (HSM) bieten einen guten Schutz für Schlüssel, die zum Signieren von Nachrichten und zur Identifizierung von Diensten/Servern verwendet werden. Sie heben das insgesamt vorhandene Sicherheitsniveau weiter an, sind aber teuer in der Anschaffung und Wartung; zudem bestehen keine Anforderungen für ein HSM nach Standard FIPS 140-2 Level 2 oder Level 3. Da ein geschlossenes Netzwerk verwendet wird, das wirksam vor Bedrohungen schützt, wurde entschieden, nicht von Anfang an ein HSM einzusetzen. Sollte es — z. B. für Akkreditierungen — notwendig werden, kann es nachträglich in die Architektur integriert werden. 3. Technische Bedingungen für den Datenaustausch 3.1. Beschreibung der Eucaris-Anwendung 3.1.1. Allgemeines Durch die Eucaris-Anwendung werden alle beteiligten Mitgliedstaaten in einem vermaschten Netz zusammengeschaltet, in dem jeder Mitgliedstaat direkt mit dem anderen kommuniziert. Für die Kommunikation ist keine zentrale Komponente erforderlich. Die Eucaris-Softwareanwendung erlaubt eine sichere Verbindung zu den anderen Mitgliedstaaten und die Kommunikation mit den Back-End Legacy-Systemen der Mitgliedstaaten unter Nutzung von XML. Die nachstehende Abbildung zeigt diese Architektur. Die Mitgliedstaaten tauschen Nachrichten durch direkte Übermittlung an den Empfänger aus. Das Datenzentrum eines Mitgliedstaats ist an das für den Nachrichtenaustausch genutzte Netzwerk (TESTA) angeschlossen. Die Mitgliedstaaten erhalten Zugang zum TESTA-Netz über ihr nationales Portal (Gate). Die Verbindung zum Netz muss über eine Firewall laufen; ein Router wiederum verbindet die Eucaris-Anwendung mit der Firewall. In Abhängigkeit von der für den Schutz der Nachrichten gewählten Option wird ein Zertifikat entweder durch den Router oder durch die Eucaris-Anwendung verwendet. Es ist eine Client-Anwendung vorhanden, die von einem Mitgliedstaat für Abfragen im eigenen nationalen Register oder in den Registern anderer Mitgliedstaaten verwendet werden kann. Sie wird mit Eucaris verbunden. Clients werden mittels Nutzer-ID/Passwort oder Client-Zertifikat identifiziert. Die Verbindung zu einem Nutzer in einer externen Stelle (z. B. Polizei) kann verschlüsselt werden, doch fällt dies in die Zuständigkeit jedes einzelnen Mitgliedstaats. 3.1.2. Anwendungsbereich des Systems Der Anwendungsbereich des Eucaris-Systems ist auf Prozesse im Zusammenhang mit dem Informationsaustausch zwischen den Registerbehörden der Mitgliedstaaten und eine Basisdarstellung dieser Informationen beschränkt. Verfahren und automatisierte Prozesse, für die die Informationen verwendet werden sollen, fallen nicht in den Anwendungsbereich des Systems. Die Mitgliedstaaten können entscheiden, ob sie die Eucaris-Client-Funktionalität nutzen oder sich ihre eigene Client-Anwendung individuell gestalten wollen. In der nachstehenden Tabelle wird dargelegt, welche Elemente des Eucaris-Systems obligatorisch bzw. vorgeschrieben sind und welche optional sind bzw. von den Mitgliedstaaten frei gewählt werden können. Eucaris aspects M/O () Remark Network concept M The concept is an „any-to-any“ communication. Physical network M TESTA Core application M The core application of Eucaris has to be used to connect to the other Member States. The following functionality is offered by the core: — Encrypting and signing of the messages — Checking of the identity of the sender — Authorization of Member States and local users — Routing of messages — Queuing of asynchronous messages if the recipient service is temporally unavailable — Multiple country inquiry functionality — Logging of the exchange of messages — Storage of incoming messages Client application O In addition to the core application the Eucaris II client application can be used by a Member State. When applicable, the core and client application are modified under auspices of the Eucaris organisation. Security concept M The concept is based on XML-signing by means of client certificates and SSL-encryption by means of service certificates. Message specifications M Every Member State has to comply with the message specifications as set by the Eucaris organisation and this Council Decision. The specifications can only be changed by the Eucaris organisation in consultation with the Member States. Operation and Support M The acceptance of new Member States or a new functionality is under auspices of the Eucaris organisation. Monitoring and help desk functions are managed centrally by an appointed Member State. (1) M = mandatory to use or to comply with; O = optional to use or to comply with. 3.2. Funktionale/nicht funktionale Anforderungen 3.2.1. Generische Funktionalität In diesem Abschnitt werden die wichtigsten generischen Funktionen in allgemeiner Form beschrieben. Nr. Beschreibung 1. Das System ermöglicht den Registerbehörden der Mitgliedstaaten einen interaktiven Austausch von Anfragen und Auskünften. 2. Das System beinhaltet eine Client-Anwendung, die Endnutzern den Versand ihrer Anfragen ermöglicht und die die Antwort für die manuelle Verarbeitung ausgibt. 3. Das System erleichtert den „Rundruf“, mit dem Mitgliedstaaten Anfragen an alle anderen Mitgliedstaaten senden können. Die eingehenden Antworten werden von der Kernanwendung in einer einzigen Antwortnachricht zusammengefasst (diese Funktionalität wird als „Mehrländerabfrage“ bezeichnet). 4. Das System kann verschiedene Arten von Nachrichten bearbeiten. Nutzerrollen, Autorisierung, Routing, Signierung und Protokollierung sind allesamt als gesonderte Dienste definiert. 5. Das System ermöglicht den Mitgliedstaaten den Austausch von Nachrichtenstapeln und Nachrichten, die eine große Anzahl von Anfragen oder Antworten enthalten. Diese Nachrichten werden asynchron bearbeitet. 6. Das System stellt asynchrone Nachrichten in eine Warteschlange, wenn der Empfängermitgliedstaat vorübergehend nicht erreichbar ist, und gewährleistet die Zustellung, sobald er wieder zur Verfügung steht. 7. Das System speichert eingehende asynchrone Nachrichten, bis sie verarbeitet werden können. 8. Das System erlaubt den Zugriff nur auf Eucaris-Anwendungen anderer Mitgliedstaaten, nicht aber auf einzelne Stellen der anderen Mitgliedstaaten, d. h., jede Registerbehörde fungiert als einziges Gateway zwischen ihren nationalen Endnutzern und den entsprechenden Registerbehörden der anderen Mitgliedstaaten. 9. Es besteht die Möglichkeit, Nutzer aus verschiedenen Mitgliedstaaten auf einem Eucaris-Server zu definieren und sie nach Maßgabe der Rechte dieses Mitgliedstaats zu autorisieren. 10. Die Nachrichten enthalten Angaben zum anfragenden Mitgliedstaat, zur anfragenden Stelle sowie zum Endnutzer. 11. Das System erleichtert die Protokollierung des Nachrichtenaustauschs zwischen den einzelnen Mitgliedstaaten sowie zwischen der Kernanwendung und den nationalen Registrierungssystemen. 12. Das System überträgt einer Stelle oder einem Mitgliedstaat die Sekretariatsfunktion und erteilt ihr/ihm ausdrücklich die Berechtigung, protokollierte Angaben über Nachrichten, die an alle Mitgliedstaaten übermittelt bzw. von diesen empfangen wurden, für die Erstellung statistischer Berichte zusammenzutragen. 13. Jeder Mitgliedstaat legt selbst fest, welche protokollierten Angaben dem Sekretariat zugänglich gemacht werden und welche „privaten“ Charakter tragen. 14. Das System ermöglicht den nationalen Administratoren jedes Mitgliedstaats, statistische Daten für den Eigenbedarf abzurufen. 15. Das System erlaubt die Aufnahme neuer Mitgliedstaaten über einfache administrative Funktionen. 3.2.2 Benutzerfreundlichkeit Nr. Beschreibung 16. Das System besitzt eine Schnittstelle für die automatisierte Verarbeitung von Nachrichten durch Back-End-/Legacy-Systeme und ermöglicht die Einbeziehung von (kundenspezifischen) Nutzerschnittstellen in diese Systeme. 17. Das System ist leicht erlernbar, selbsterklärend und enthält Hilfetext. 18. Zum System gehört eine Dokumentation, die den Mitgliedstaaten die Einbindung des Systems sowie den operationellen Betrieb und künftige Wartungsarbeiten ermöglicht (z. B. Handbücher, Bedienungsanleitungen, technische Unterlagen, Betriebsunterlagen usw.). 19. Die Nutzerschnittstelle ist mehrsprachig ausgelegt und bietet dem Endnutzer die Möglichkeit zur Auswahl der von ihm bevorzugten Sprache. 20. Die Nutzerschnittstelle ermöglicht es dem Administrator vor Ort, Bildschirmanzeigen und codierte Informationen in die von ihm bevorzugte Sprache zu übersetzen. 3.2.3. Zuverlässigkeit Nr. Beschreibung 21. Das System soll robust und betriebssicher gestaltet sein und Anwenderfehler, Stromausfälle und andere Problemfälle ohne Schwierigkeiten bewältigen. Es muss möglich sein, das System ohne oder mit minimalem Datenverlust neu zu starten. 22. Das System soll stabile und reproduzierbare Ergebnisse liefern. 23. Das System ist so gestaltet, dass es zuverlässig funktioniert. Es soll den Betrieb mit einer Konfiguration ermöglichen, die eine 98 %ige Verfügbarkeit (durch Redundanz, Verwendung von Backup-Servern usw.) bei jeder bilateralen Kommunikation garantiert. 24. Es sollte möglich sein, auch bei Ausfall einiger Komponenten einen Teil des Systems zu nutzen (wenn Mitgliedstaat C ausfällt, müssen die Mitgliedstaaten A und B noch miteinander kommunizieren können). Die Zahl der punktuellen Ausfälle in der Informationskette soll möglichst gering gehalten werden. 25. Die Einsatzfähigkeit nach einem größeren Ausfall muss innerhalb eines Tages wiederhergestellt sein. Es muss möglich sein, die Ausfallzeit durch Inanspruchnahme von Fernbetreuung, beispielsweise durch einen zentralen Service-Desk, auf ein Mindestmaß zu reduzieren. 3.2.4. Leistungsfähigkeit Nr. Beschreibung 26. Das System muss 7 Tage rund um die Uhr einsetzbar sein. Diese zeitliche Vorgabe (7 Tage rund um die Uhr) muss dann auch von den Legacy-Systemen der Mitgliedstaaten erfüllt werden. 27. Das System muss unabhängig von laufenden Hintergrundprogrammen schnell auf Nutzeranfragen reagieren. Diese Vorgabe gilt auch für die Legacy-Systeme der Teilnehmer, damit eine akzeptable Ansprechzeit sichergestellt wird. Eine Gesamtantwortzeit von 10 Sekunden pro Einzelanfrage ist vertretbar. 28. Das System ist als Multi-User-System so zu gestalten, dass Hintergrundprogramme laufen können, während der Nutzer Vordergrundprogramme ausführt. 29. Das System ist skalierbar zu gestalten, um etwaige Steigerungen der Nachrichtenanzahl bewältigen zu können, wenn neue Funktionalitäten bzw. neue Stellen oder Mitgliedstaaten in das System aufgenommen werden. 3.2.5. Sicherheit Nr. Beschreibung 30. Das System muss (z. B. in Bezug auf sein Sicherheitskonzept) für den Austausch von Nachrichten mit sensiblen personenbezogenen Daten (z. B. über Besitzer/Halter von Kraftfahrzeugen), die als „EU restricted“ eingestuft sind, geeignet sein. 31. Das System ist so einzurichten, dass jeder unbefugte Zugriff auf Daten verhindert wird. 32. Das System enthält ein Managementprogramm für Rechte und Befugnisse der nationalen Endnutzer. 33. Die Mitgliedstaaten müssen in der Lage sein, die Identität des Absenders über die XML-Signatur (auf Ebene des Mitgliedstaats) zu prüfen. 34. Die Mitgliedstaaten müssen anderen Mitgliedstaaten die ausdrückliche Genehmigung zum Abruf von Informationen erteilen. 35. Das System beinhaltet auf Anwendungsebene ein umfassendes Sicherheits- und Verschlüsselungskonzept, das dem für solche Fälle angemessenen Sicherheitsniveau genügt. Vertraulichkeit und Integrität der Informationen sind durch Verwendung der XML-Signatur und verschlüsselte Übertragung mit SSL-Tunnel zu gewährleisten. 36. Jeder Nachrichtenaustausch kann mittels Protokollierung nachvollzogen werden. 37. Ein Schutz gegen Löschattacken (Löschung einer Nachricht durch einen Dritten) und gegen Wiedereinspiel- oder Einfügungsattacken (Wiedereinspielung oder Einfügung einer Nachricht durch einen Dritten) muss gegeben sein. 38. Das System verwendet Zertifikate einer vertrauenswürdigen dritten Partei (Trusted Third Party — TTP). 39. Das System kann mit den in den Mitgliedstaaten je nach Nachrichten- oder Dienstart verwendeten unterschiedlichen Zertifikaten arbeiten. 40. Die Sicherheitsmaßnahmen auf Anwendungsebene sind ausreichend, so dass die Verwendung von nicht akkreditierten Netzwerken möglich ist. 41. Das System erlaubt die Verwendung neuer Sicherheitstechniken wie der XML-Firewall. 3.2.6. Anpassungsfähigkeit Nr. Beschreibung 42. Das System lässt sich durch Aufnahme neuer Nachrichtenarten und Funktionalitäten erweitern. Die Anpassungskosten sollen aufgrund der zentralen Entwicklung von Anwendungskomponenten möglichst gering sein. 43. Es muss den Mitgliedstaaten möglich sein, neue Nachrichtenarten für den bilateralen Gebrauch zu definieren. Es ist nicht erforderlich, dass alle Mitgliedstaaten jede Nachrichtenart unterstützen. 3.2.7. Betreuung und Wartung Nr. Beschreibung 44. Das System sieht Überwachungseinrichtungen für einen zentralen Service-Desk und/oder Operatoren bezüglich des Netzwerks und der Server in den verschiedenen Mitgliedstaaten vor. 45. Das System sieht Einrichtungen zur Fernbetreuung durch einen zentralen Service-Desk vor. 46. Das System sieht Einrichtungen zur Problemanalyse vor. 47. Das System lässt sich auf neue Mitgliedstaaten erweitern. 48. Die Anwendung kann durch Personal mit einem Minimum an IT-Kenntnissen und -Erfahrungen installiert werden. Die Installation sollte weitgehend automatisiert erfolgen. 49. Das System bietet eine ständige Test- und Akzeptanzumgebung. 50. Die jährlichen Kosten für Wartung und Betreuung sind durch Übernahme von Marktstandards und durch Einsatz einer solchen Anwendung, die nur wenig Betreuung durch einen zentralen Service-Desk erfordert, möglichst gering zu halten. 3.2.8. Konzeptionelle Vorgaben Nr. Beschreibung 51. Konzeption und Dokumentation des Systems sind für einen langjährigen Betriebszeitraum ausgelegt. 52. Das System ist so zu konzipieren, dass es vom Netzbetreiber unabhängig ist. 53. Das System ist mit der in den Mitgliedstaaten verwendeten Hardware/Software kompatibel, in dem es mit deren Registrierungssystemen unter Nutzung von Web-Service-Technologien mit offenen Standards (XML, XSD, SOAP, WSDL, HTTP(s), Web services, WSS, X.509 usw.) kommuniziert. 3.2.9. Anwendbare Standards Nr. Beschreibung 54. Das System erfüllt die Datenschutzvorschriften der Verordnung (EG) Nr. 45/2001 (Artikel 21, 22 und 23) sowie der Richtlinie 95/46/EG. 55. Das System erfüllt die IDA-Standards. 56. Das System unterstützt UTF8. KAPITEL 4: Bewertung 1. Bewertungsverfahren gemäß Artikel 20 (Vorbereitung der in Artikel 25 Absatz 2 des Beschlusses 2008/615/JI genannten Beschlüsse) 1.1. Fragebogen Die zuständige Ratsarbeitsgruppe erstellt einen Fragebogen für jede Art von automatisiertem Datenaustausch gemäß Kapitel 2 des Beschlusses 2008/615/JI. Geht ein Mitgliedstaat davon aus, dass er die Voraussetzungen für einen Austausch von Daten der jeweiligen Kategorie erfüllt, so beantwortet er die entsprechenden Fragen. 1.2. Testlauf Im Hinblick auf die Auswertung des Fragebogens führt der Mitgliedstaat, der mit dem Datenaustausch beginnen möchte, zusammen mit einem oder mehreren anderen Mitgliedstaaten, die bereits am Datenaustausch im Rahmen des Ratsbeschlusses beteiligt sind, einen Testlauf durch. Der Testlauf erfolgt kurz vor oder kurz nach dem Bewertungsbesuch. Die Bedingungen und Modalitäten für diesen Testlauf werden auf der Grundlage einer zuvor mit dem betreffenden Mitgliedstaat geschlossenen gesonderten Vereinbarung von der zuständigen Ratsarbeitsgruppe festgelegt. Die an dem Testlauf beteiligten Mitgliedstaaten regeln die praktischen Einzelheiten. 1.3. Bewertungsbesuch Im Hinblick auf die Auswertung des Fragebogens wird ein Bewertungsbesuch in dem Mitgliedstaat durchgeführt, der mit dem Datenaustausch beginnen möchte. Die Bedingungen und Modalitäten für diesen Bewertungsbesuch werden auf der Grundlage einer zuvor zwischen dem betreffenden Mitgliedstaat und dem Bewertungsteam geschlossenen gesonderten Vereinbarung von der zuständigen Ratsarbeitsgruppe festgelegt. Der betreffende Mitgliedstaat ermöglicht dem Bewertungsteam die Kontrolle des automatisierten Datenaustauschs in der bzw. den zu bewertenden Datenkategorien insbesondere durch Erstellung eines Besuchsprogramms, das dem Auftrag des Bewertungsteams Rechnung trägt. Innerhalb eines Monats erarbeitet das Bewertungsteam einen Bericht über den Bewertungsbesuch und leitet ihn dem betreffenden Mitgliedstaat zur Stellungnahme zu. Gegebenenfalls wird der Bericht auf der Grundlage der Stellungnahme des Mitgliedstaats vom Bewertungsteam überarbeitet. Das Bewertungsteam besteht aus maximal drei Experten, die von den am automatisierten Datenaustausch in der bzw. den zu bewertenden Datenkategorien beteiligten Mitgliedstaaten ernannt werden. Diese Experten müssen über Erfahrungen mit der betreffenden Datenkategorie verfügen, im Besitz ausreichender Sicherheitsermächtigungen für die Behandlung dieser Fragen sein und bereit sein, an mindestens einem Bewertungsbesuch in einem anderen Mitgliedstaat teilzunehmen. Die Kommission wird ersucht, sich dem Bewertungsteam als Beobachter anzuschließen. Die Mitglieder des Bewertungsteams wahren die Vertraulichkeit der Informationen, von denen sie bei der Durchführung ihres Auftrags Kenntnis erhalten. 1.4. Bericht an den Rat Dem Rat wird zur Vorbereitung seines Beschlusses gemäß Artikel 25 Absatz 2 des Beschlusses 2008/615/JI ein Gesamtbericht mit einer umfassenden Evaluierung der Ergebnisse der Fragebogen, des Bewertungsbesuchs und des Testlaufs vorgelegt. 2. Bewertungsverfahren gemäß Artikel 21 2.1. Statistiken und Bericht Jeder Mitgliedstaat stellt Statistiken zu den Ergebnissen des automatisierten Datenaustauschs auf. Das Statistikmodell wird von der zuständigen Ratsarbeitsgruppe erarbeitet, um die Vergleichbarkeit der Daten zu gewährleisten. Diese Statistiken werden jährlich dem Generalsekretariat, das einen zusammenfassenden Überblick über das abgelaufene Jahr erstellt, sowie der Kommission zugeleitet. Darüber hinaus werden die Mitgliedstaaten gebeten, regelmäßig, aber nicht häufiger als einmal pro Jahr weitere Angaben über die verwaltungsmäßige, technische und finanzielle Umsetzung des automatisierten Datenaustauschs vorzulegen, damit das Verfahren — wenn nötig — analysiert und verbessert werden kann. Anhand dieser Informationen wird ein Bericht für den Rat erstellt. 2.2. Überarbeitung Der Rat wird das hier beschriebene Bewertungsverfahren binnen einer angemessenen Frist prüfen und erforderlichenfalls überarbeiten. 3. Treffen von Experten Die Experten treffen im Rahmen der zuständigen Ratsarbeitsgruppe regelmäßig zur Vorbereitung und Durchführung der vorgenannten Bewertungsverfahren sowie zum Erfahrungsaustausch und zur Erörterung etwaiger Verbesserungen zusammen. Die Ergebnisse dieser Expertenberatungen werden gegebenenfalls in den Bericht gemäß Punkt 2.1 aufgenommen. ( ) Vollständig bestimmt bzw. belegt („full designated“) verweist auf die Einbeziehung seltener Allelwerte.