Jusletter IT

Once Only Prinzip in der Single Digital Gateway Verordnung – Status und Erkenntnisse

  • Authors: Carl-Markus Piswanger / Björn Lellmann / Felix Plank
  • Category of articles: E-Government
  • Region: Austria, EU
  • Field of law: E-Government
  • Collection: Conference proceedings IRIS 2023
  • DOI: 10.38023/dc01a23e-97f8-40d4-a31f-7e7324b8d1ef
  • Citation: Carl-Markus Piswanger / Björn Lellmann / Felix Plank, Once Only Prinzip in der Single Digital Gateway Verordnung – Status und Erkenntnisse, in: Jusletter IT 23 February 2023
The Once Only Principle in the Single Digital Gateway Regulation is due to be operative in December 2023 with supranational evidence exchange within a significant number of public procedures; described in Article 14 of the regulation. Austria is required to establish a Once Only Technical System to connect with other European member states. This technical system is described in its technical and organisational dimensions in an implementing regulation. The Austrian approach for the Once Only Technical System follows the path of best possible support of the technical and organisational environment involved. Therefore, an open approach has been established, with ongoing clarifications, discussions and information sharing for and with stakeholders; technically this approach is reflected by a Shared Services architecture. A survey, conducted among eGovernment experts, has shown that the chosen IT-architecture and its principles are balanced and appropriate for a sustainable future use.

Inhaltsverzeichnis

  • 1. Single Digital Gateway Verordnung und das Once Only Prinzip
  • 2. Organisation der Umsetzung des österreichischen OOTS
  • 3. Architektur des österreichischen OOTS
  • 4. Komponenten der Architektur des österreichischen OOTS
  • 4.1. Verfahrensportale und Datendienste
  • 4.2. Technische Plattform für Online-Dialoge (Online-Dialog Plattform)
  • 4.3. Intermediäre Plattform
  • 4.4. eDelivery Zugangspunkt und die europäischen Gemeinsamen Dienste
  • 4.5. Weitere Systeme
  • 5. Ergebnisse einer Umfrage zur Architektur des österreichischen OOTS
  • 6. Literatur

1.

Single Digital Gateway Verordnung und das Once Only Prinzip ^

[1]

Die Single Digital Gateway Verordnung (SDGR) stellt ein europäisches Gesetz dar, das „...die Einrichtung eines einheitlichen digitalen Zugangstors zu Informationen, Verfahren, Hilfs- und Problemlösungsdiensten...“ beinhaltet.1 Im Artikel 14 der SDGR findet sich das Once Only Prinzip2 (SDG-OOP) definiert, in dem der automatisierte Austausch von Nachweisen zwischen Mitgliedstaaten geregelt ist. Dieser Austausch wird über ein „...technisches System zur einmaligen Erfassung“ (OOTS)3 stattfinden, das von der Europäischen Kommission in Zusammenarbeit mit den Mitgliedstaaten aufgebaut wird und mit dem Stichtag 12.12.2023 seinen Betrieb aufnehmen soll. Die Verfahrensbereiche für den Austausch von Nachweisen mittels SDG-OOP sind in der SDGR an zwei Stellen definiert, einerseits 21 Verfahren, die im Annex II der SDGR definiert sind, und zudem vier Richtlinien, die direkt im Artikel 14 der SDGR angeführt sind. Die Umsetzung des OOTS soll die Möglichkeit bieten, Nachweise aus Datendiensten über Ländergrenzen hinweg aufzufinden, sowie die technischen Mechanismen beinhalten, diese Daten zugänglich und adressierbar zu machen. Besonders hervorzuheben ist die Qualitätssicherung der ausgetauschten Daten, die durch eine Vorschaufunktionalität (Preview) der ausgetauschten Daten gewährleistet wird, die für den/die Anwender:in erbracht wird, bevor die Daten übermittelt werden. Die Durchführungsverordnung zur SDGR mit den technischen und operativen Spezifikationen des OOTS ist im August 2022 publiziert worden.

2.

Organisation der Umsetzung des österreichischen OOTS ^

[2]

In den folgenden Ausführungen werden aktuelle Schritte der österreichischen Umsetzung des OOTS dargestellt, und zwar {1} ein Überblick über den organisatorischen Aufbau der OOTS-Umsetzung in Österreich, {2} die österreichischen Tätigkeiten in Form einer Darstellung der (in Umsetzung befindlichen) technischen Architektur und der Systeme des österreichischen IT-Systemverbunds zur Umsetzung des OOTS, sowie {3} ein Überblick über die Ergebnisse einer Umfrage, die als begleitende Evidenzmaßnahme zur Definition der konkreten Architektur und deren Funktionsweisen des österreichischen IT-Systemverbunds des OOTS.

[3]

Die Umsetzung des OOTS in Österreich umfasst mehrere Stakeholder. Diese sind {1} die Betreiber von Verfahrensportalen, über die Anwender:innen ihre Nachweise für das/die jeweiligen Verfahren über das OOTS beziehen wollen, {2} den Datendiensten von Nachweislieferanten, die diese Nachweise gemäß der Anfrage über das OOTS zur Verfügung stellen, sowie {3} der Europäischen Kommission, die für den Aufbau des gesamten OOTS (in Zusammenarbeit mit den Mitgliedstaaten) zuständig ist, sowie selbst einen zentralen Teil des OOTS, Gemeinsame Dienste (Common Services), aufbaut und in weiterer Folge betreibt.4

[4]

Im Unternehmensserviceportalgesetz (USPG) ist in Paragraph 1(3) „...die Einrichtung einer Once-Only-Plattform, die das Ziel verfolgt, dass keine über das unbedingt notwendige Ausmaß hinausgehenden Verwaltungslasten aus Informationsverpflichtungen für Bürgerinnen und Bürger oder Unternehmen verursacht und die technischen Rahmenbedingungen für den behördenübergreifenden Informationsaustausch vereinfacht werden.“ definiert.5 Zentrale, explizit angeführte, Komponenten dieser Once-Only-Plattform stellen die IT-Systeme Register- und Systemverbund (RSV) sowie die Informationsverpflichtungsdatenbank dar. Eine Umsetzung des SDG-OOP ist im Naheverhältnis zum nationalen Once Only Prinzip zu sehen, zumal die technischen Systeme einer österreichischen Once-Only-Plattform durch das USPG schon definiert vorliegen.

[5]

Ein wichtiger Aspekt der Umsetzung von OOP ist die Kooperation auf nationaler und europäischer Ebene, und zwar sowohl in den technischen wie in organisatorischen Bereichen. Auf organisatorischer Ebene sind das vor allem die Abstimmungen mit Organisationen aus zwei Umwelten, zum einen die Nachweis anfordernde Behörde mit dem Verfahrensportal (als datenanfragende Instanz), sowie zum anderen der Nachweislieferant mit den Datendiensten (als Daten zur Verfügung stellende Instanz). Auf europäischer Ebene finden sich hierzu die Europäische Kommission (EK) sowie Vertreter:innen von Organisationen der Mitgliedstaaten, die in den Arbeitsgruppen der EK gemäß der Durchführungsverordnung zum OOTS tätig sind. In der Durchführungsverordnung sind Arbeitsgruppen, die sogenannte Koordinierungsgruppe und ihre fachlich und technischen Untergruppen definiert worden.6 Die Untergruppen sind: {1} Operative Governance, {2} Sicherheit des OOTS sowie {3} Erprobung und Einführung der Komponenten des OOTS; {4} Standardisierung von Datenmodellen des OOTS sowie {5} Zuordnung der Nachweise sowie {6} Überprüfung, Pflege und Auslegung der technischen Entwurfsdokumentation.

3.

Architektur des österreichischen OOTS ^

[6]

Die Umsetzung des österreichischen OOTS stellt einen Systemverbund dar. Eine Aufgabe der nationalen Anstrengungen zur Analyse der Architektur war die Schaffung von unterschiedlichen Implementierungsvarianten und eine Lösung mit geeigneten Abstufungen für unterschiedliche „Service-Tiefen“. Aufgrund der Tatsache, dass mehrere technisch unterschiedliche IT-Systeme der beiden zentralen nationalen Umwelten der Verfahrensportale und der Datendienste auf zentrale IT-Systeme des österreichischen OOTS zugreifen, ist es vorteilhaft, diese Services in einer standardisierten Weise als Shared Services bereitzustellen. Dies hat große Auswirkungen auf das Management von Schnittstellen zwischen den einzelnen Systemen.

[7]

Das österreichische OOTS bedient sich einerseits Systemen des österreichischen E-Government, inklusive der Once-Only-Plattform (mit RSV), wie auch einer Reihe von neu aufzubauenden Systemen/Komponenten, die spezifisch Prozesse des SDG-OOP umsetzen. Zu den zentralen österreichischen Komponenten, die bei SDG-OOP Verwendung finden, zählen neben den erwähnten IT-Systemen des RSV (und der IVDB) auch die österreichische technische Infrastruktur der eIDAS-Identifikation sowie das Authentisierungssystem des österreichischen Portalverbunds.

Abbildung 1: Überblick des OOP-Prozesses im OOTS (mit Systemen im Systemverbund)

[8]

Die obige Abbildung zeigt die einzelnen Systembereiche innerhalb des österreichischen OOTS-Systemverbunds in einer prozesshaften Darstellung; für beide Bereiche, die der Nachweise anfordernden Behörde (oberer Teil) sowie des Nachweislieferanten (unterer Teil).7 Zudem sind „Corner“ eingezeichnet, da in Bezug auf die Nutzung des europäischen eDelivery-Building Blocks oft von einem 4-Corner-Model gesprochen wird,8 das die vier zentralen Beteiligten im System abbildet.9

[9]

Das SDG-OOP weist in mehreren Bereichen Herausforderungen auf: Diese liegen zum einen in notwendigen Online Dialogen, inklusive der Prozesse der Übergabe und Rückführung des/der Anwender:in zwischen den Mitgliedstaaten. Die Online Dialoge sind im Gesamtprozess mehrfach notwendig und werden sowohl auf Seiten der die Nachweise anfordernden Behörde als auch auf Seiten des Nachweislieferanten durchgeführt. So befindet sich in der Abfolge der Online Dialoge eine notwendige eIDAS-Identifikation aufseiten der Nachweise anfordernden Behörde, vor dem Prozess des Ausdrücklichen Ersuchens (Explicit Request), sowie potentiell unter bestimmten Voraussetzungen als erneute Authentifizierung auf Seiten des Nachweislieferanten.

[10]

Ein weiterer herausfordernder Bereich liegt in der Identifikation der anzufordernden Nachweise. Die Identifikation der anzufordernden Nachweise erfolgt dabei über das Konzept des Kriteriums.10 Dieser steht für eine konkrete Anforderung eines Verfahrens, welche durch den anzufordernden Nachweis belegt werden soll; beispielsweise die Vorlage gewisser Informationen wie des Geburtsdatums, der Nationalität, oder über das Bestehen einer Tatsache wie der Volljährigkeit. Diese Kriterien werden durch die Mitgliedstaaten definiert. In einem nächsten Schritt werden den Kriterien wiederum, durch die Mitgliedstaaten, Nachweisarten zugeordnet, welche zum Beleg des jeweiligen Kriteriums aus dem jeweiligen Mitgliedstaat geliefert werden können. Gemäß diesen in den Gemeinsamen Diensten gespeicherten Informationen kann die benötigte Nachweisart angefordert werden und somit der konkrete Nachweis als elektronisches Dokument verschickt werden. Diese flexible Herangehensweise mittels Kriterien unterstützt die Datenminimierung, damit nur die dem Kriterium entsprechende notwendige Information enthalten ist.

[11]

Die eIDAS-Verordnung ist von Wichtigkeit, denn elektronische Identifikation und Vertrauensdienste sind auch für das SDG-OOP anzuwenden, eine Identifikation des/der Anwender:in mit einer eIDAS-notifizierten eID vor dem Prozess des Ausdrücklichen Ersuchens notwendig. In Bezug auf Vertrauensdienste in der eIDAS-Verordnung ist im Erwägungsgrund 8 der Durchführungsverordnung zum OOTS der Artikel 44 der eIDAS-Verordnung erwähnt, also die Anforderungen an qualifizierte Dienste für die Zustellung elektronischer Einschreiben.11 In Bezug auf die Datenschutz-Grundverordnung (GDPR) ist die Vorschaufunktion (Preview) auf der Seite des Nachweislieferanten durchzuführen, was eine zweifache Anwender:innen-Weiterleitung mit sich bringt, und zwar von der Nachweisanfordernden Behörde hin zum Nachweislieferanten und danach wieder zurück.

[12]

Nationale Basiskomponenten des E-Government finden Wiederverwendung bei der Umsetzung des österreichischen OOTS, so stellt der RSV als zentrales österreichisches Once-Only-System auch im SDG-OOP das zentrale IT-System der Intermediären Plattform (Intermediary Platform) dar. Auch die für das österreichische OOTS aufzubauenden technischen Systeme sollen wiederum größtmöglich als Shared Services dem österreichischen (oder europäischen) E-Government zur Verfügung stehen.

4.

Komponenten der Architektur des österreichischen OOTS ^

[13]

Den oben dargestellten Architekturprinzipien oder den Vorgaben und Erarbeitungen (national/international) folgend wurden in den Architekturanalysen dedizierte Systembereiche identifiziert, die sich in vier Säulen unterteilen lassen, {1} dem Verfahrensportal oder Datendienst, {2} der Technischen Plattform für Online-Dialoge, der {3} Intermediären Plattform und {4} Technische Systeme für den Datenaustausch sowie die europäischen Gemeinsamen Dienste. Die Architekturprinzipien wurden zusätzlich in Abstimmungen mit externen Expert:innen-Kreisen und den Vorgaben der EK abgestimmt und darüber hinaus mittels einer Umfrage bei E-Government-Expert:innen untermauert. Ein Überblick über die Ergebnisse der Umfrage sind im Kapitel 5 dargestellt.

4.1.

Verfahrensportale und Datendienste ^

[14]

Die Verfahrensportale (aufseiten der Nachweise anfordernden Behörden) und die Datendienste (aufseiten der Nachweislieferanten) stellen die beiden technischen Instanzen bei den Transaktionen dar. Während der/die Anwender:in im Verfahrensportal die Evidenzen für das konkrete Verfahren benötigt, werden diese, wie oben dargestellt, von Datendiensten zur Verfügung gestellt. Im Speziellen ist im SDG-OOP der/die Anwender:in durch die Übergabe des/der Anwender:in in die Hemisphäre der Datendienste (oder einer Intermediären Plattform auf dessen Seite) zur Durchführung der Vorschaufunktion mit beiden Welten in Interaktion und stellen demgemäß beide Funktionen zur Interaktionen mit dem/der Anwender:in zur Verfügung – sofern diese nicht von einer zentralen Dialog-Plattform durchgeführt werden (siehe 4.2.). Technisch gesehen ist es dabei wichtig, dass die notwendigen technischen Adressierungen zum ersten zu einem technischen System bei den Datendiensten (oder einer diesbezüglichen Intermediären Plattform) und zurück zum Verfahrensportal (oder einer diesbezüglichen Intermediären Plattform) rechtzeitig und in einer standardisierten Weise ausgetauscht werden. Dies findet über eine Iteration von technischen Kommunikationen über den eDelivery-Zugangspunkt (das AS4-Gateway des „Access Point“) statt, in dem die beiden Adressierungen übermittelt werden.

4.2.

Technische Plattform für Online-Dialoge (Online-Dialog Plattform) ^

[15]

Der Gesamtprozess einer SDG-OOP-Transaktion umfasst, wie bereits dargestellt, eine signifikante Anzahl von Online-Dialogen bei mehreren Beteiligten. Diese Dialoge sind heterogen und aufeinander aufbauend oder anschließend. Diese Dialoge sind grundsätzlich als Teil der Verfahrensportale und gegebenenfalls auch Datendienste zu sehen, können jedoch auch einheitlich und zentral als Online-Dialog Plattform, in diesem Sinne eine Shared Service Plattform, den bedarfstragenden Entitäten zur Verfügung gestellt werden. Ein derartiges Vorgehen wurde auch von der EK als „Staging Area“ (als Teil der Intermediären Plattform) in Form einer Umsetzungsvariante vorgeschlagen. Die Umfrageergebnisse (in Kapitel 5) sprechen von einem signifikanten Potential für eine derartige Shared Service-Lösung, zur freiwilligen Nutzung der bedarfstragenden Entitäten.

Abbildung 2: Integrationsvarianten von Online-Dialogen und Web-Service-Nutzung als Shared Services

[16]

Die Online-Dialoge können grundsätzlich individuell aufgebaut sein, für die Umsetzung einer zentralen Online-Dialog-Plattform als Shared Service für das österreichische OOTS sind folgende Inhalte und Interaktionen definiert worden: Für Interaktionen aufseiten der Nachweise anfordernden Behörde sind das {1} Informations­seiten mit grundsätzlichen Informationen (z.B. Prozessdarstellungen, Datenschutzinformationen), {2} die Dialoge zur Interaktion mit den europäischen Gemeinsamen Diensten, {3} eine fakultative eIDAS-Identifikation (falls noch nicht davor schon stattgefunden) und {4} das Ausdrückliche Ersuchen (Explicit Request) für die Anforderung der Evidenz durch den/die Anwender:in.

[17]

Die Interaktionen aufseiten der Nachweiselieferanten sind {1} ebenfalls Informationsseiten sowie {2} eine fakultative eIDAS-Identifikation und {3} der Vorschaubereich. Der Schritt der ersten eIDAS-Identifikation ist zwingend, kann jedoch an unterschiedlichen Stellen vorkommen, zum Beispiel schon bei einem Single-Sign-On in das Verfahrensportal, spätestens jedoch vor dem Schritt des ausdrücklichen Ersuchens.12 Weitere Online-Dialoge finden im Rahmen der Abfragen bei den europäischen Gemeinsamen Diensten statt. Diese Dienste bestehen unter anderem aus den technischen Services Nachweisdienst sowie dem Verzeichnis der Datendienste. An diese Online-Services kann die anfragende Stelle technische Anfragen stellen, die einerseits den/die zu bestellende Nachweis definieren lassen,13 zum anderen den konkreten Datendienst, der die Nachweise liefert, abfragen. Weitere Informationspflichten und Support-Maßnahmen für die Anwender:innen ergänzen die Interaktionen.

4.3.

Intermediäre Plattform ^

[18]

Die Intermediäre Plattform stellt in der österreichischen Ausprägung eine technische Plattform zur Verfügung, die aus dem österreichischen Once-Only-Kernsystem des RSV sowie begleitender unterstützender IT-Anwendungen besteht. Das zentrale österreichische System für Once-Only, der RSV, stellt das IT-System für die Datenabfrage bei den angeschlossenen österreichischen Datendiensten dar. Unterstützende Anwendungen sind für die Verarbeitung von logischen Regeln, der Verarbeitung von technischen Prozessen (inkl. Schnittstellenmanagement) sowie der Speicherung von technischen Artefakten notwendig. Diese technische Plattform stellt Web Services zur Verfügung – im Speziellen für die Abfrage bei den europäischen Gemeinsamen Diensten sowie für das Technische Anfrage- und Antwort-Management, die sowohl von externen Beteiligten (z.B. Verfahrensportalen und Datendiensten) als Shared Services genutzt werden können, jedoch auch von der zentralen Dialog-Plattform genutzt wird (siehe Abbildung 2 – Mitte).

4.4.

eDelivery Zugangspunkt und die europäischen Gemeinsamen Dienste ^

[19]

Die Architektur für SDG-OOP wird durch technische Systeme komplettiert. Diese Systeme sind rund um den eDelivery-Zugangspunkt unter Nutzung eines AS4-Datenübermittlungsprotokolls (AS4-Gateway) gruppiert und ermöglichen die technischen Kommunikationen zwischen den einzelnen Beteiligten im eigenen Mitgliedsstaat oder den Austausch von Anfrage und Antwort mit dem anderen Mitgliedsstaat.

[20]

Die Gemeinsamen Dienste werden in den Transaktionen im Rahmen der Online Dialoge der Anwender:innen-Interaktionen auf technischer Ebene abgefragt. Gemäß der Durchführungsverordnung steht es den Mitgliedsstaaten jedoch frei, diese Systeme auch national anzubieten.14

4.5.

Weitere Systeme ^

[21]

Die vier oben beschriebenen Technikbereiche werden zudem noch von weiteren Anwendungen unterstützt, die vor allem für die Erreichung von Transparenz und Nachvollziehbarkeit dienen. Dies ist zum Beispiel ein System für das Logging von Transaktionen, wie auch mögliche Support und Informationssysteme.

5.

Ergebnisse einer Umfrage zur Architektur des österreichischen OOTS ^

[22]

Für den Aufbau eines von der Anzahl der IT-Anwendungen, wie auch deren Komplexität (und Neuheit) herausfordernden Systemverbunds, ist es notwendig evidenzbasiert zu arbeiten. Nach den technischen Analysen für den Aufbau der Architektur, wurden diese mehreren Expert:innen-Gruppen (national und international) vorgestellt und besprochen. Zusätzlich wurde eine Umfrage bei E-Government-Expert:innen durchgeführt, in der verschiedene Umsetzungsvarianten strukturiert abgefragt wurden. Die Ergebnisse sollen hier in Kürze dargestellt werden. Im Gesamten wurden 15 Expert:innen aus dem E-Government-Umfeld befragt, wobei sowohl Vertreter:innen aus der Wissenschaft wie auch der Verwaltung eingeladen wurden. Zudem wurde eine externe Sicht aus einer ausländischen Wissenschaftsorganisation eingebunden.15

[23]

Die Umfrage wurde in Form von zwölf Online-Interviews sowie drei Präsenz-Interviews durchgeführt. Mehrere Varianten der Umsetzungsmöglichkeiten wurden dabei vorgestellt. Den Expert:innen wurden unterschiedliche Varianten der Umsetzung des österreichischen OOTS in Bezug auf die Online-Dialog Plattform, je vier Varianten für Verfahrensportale und vier Varianten für die Datendienste, vorgelegt. Die Varianten spannten einen Bogen von einem sehr dezentralen Aufbau bis hin zu einem sehr zentralen Architekturmodell, sowie zwei Zwischenformen:

  • [1] Integration der Online-Dialoge ausschließlich in/bei den Verfahrensportalen oder Datendiensten
  • [2] Integration der Online-Dialoge in/bei den Verfahrensportalen oder Datendiensten, jedoch Nutzung eines Shared Services (Verfahrensportal: Abfrage der Gemeinsamen Dienste, Datendienste: Vorschaufunktion) aus der Online-Dialog Plattform
  • [3] Nutzung der Online-Dialog Plattform, jedoch Ansteuerung jedes Online-Dialogs explizit durch das Verfahrensportal oder den Datendienst
  • [4] Durchgängige Nutzung der Online-Dialog Plattform in vollem Umfang; aufeinander aufbauende Online-Dialoge direkt in der Plattform
[24]

Es wurde gebeten, diese jeweils vier Varianten einer Bewertung von 1 (sehr präferiert) bis 4 (nicht präferiert) – einem „Rating“ – zu unterziehen. Zwei Zusatzfragen wurden hinzugefügt, die eine mögliche Bereitschaft zur Nutzung offener Software-Bausteine (Building Blocks) erheben sollte, wie auch eine Einschätzung eines Individualisierungsgrades von grafischen/informatorischen Elementen (Look&Feel) im Falle einer Nutzung der zentralen Dialog-Plattform.

[25]

Die Ergebnisse können folgendermaßen zusammengefasst werden:

  • Fragen zu den jeweils vier Varianten:
    • Bei der Verortung der Online-Dialogen finden sich beide Welten in den Vorlieben vertreten, sowohl die dezentrale, direkt in den Verfahrensportalen befindlichen Dialoge, wie auch die Nutzung einer zentralen Online-Dialog Plattform als Shared Service; die Nutzung der zentralen Plattform wurde hier öfter präferiert (gemäß einem „Score“ über die einzelnen „Ratings“). Die persönliche Vorliebe zur Nutzung einer zentralen Online-Dialog Plattform als Shared Service wurde aufseiten der Daten
    • dienste minimal stärker präferiert als aufseiten der Verfahrensportale. Folgender Score wurde bei den Varianten erreicht:16
      • Verfahrensportale: [1] 7, [2] 19, [3] 18, [4] 28
      • Datendienste: [1] 6, [2] 17, [3] 21, [4] 28
    • Obwohl in der Umfrage hauptsächlich die Abfrage einer dezentralen oder zentralen Nutzung der interaktiven Online-Dialoge adressiert wurde, ist in den Varianten auch die Präferenz einer Nutzung der technischen Web Services der Intermediären Plattform von der Variantenabfrage umfasst gewesen; hierzu wurde mit großer Mehrheit, fast ausschließlich, eine Nutzung dieser Web Services als Shared Services präferiert.
    • Gleiches wie für die Web Services der Intermediären Plattform kann über die Nutzung der Technischen Systeme für den Datenaustausch angenommen werden; auch wenn nicht explizit abgefragt, waren sie in den Varianten dargestellt und so kann auch eine Präferenz für eine zentrale Nutzung abgeleitet werden.
  • Zur ersten Zusatzfrage: Eine mögliche Nutzung von verfügbaren Software-Bausteinen für eine technische Basis im Falle eines dezentralen Architektur-Aufbaues wurde mit sehr großer Mehrheit positiv beschieden, das entspricht auch dem großen Interesse an der Nutzung von Shared Services.
  • Zur zweiten Zusatzfrage: Das Bild zur Frage eines einheitlichen oder (teil-)individualisierten Look&Feels im Falle der Nutzung einer zentralen Online-Dialog-Plattform hat ein geteiltes Bild gezeigt. 60% aller Expert:innen präferierten eine (Teil-)Individualisierung des Erscheinungsbildes, zu 40% war hier der Zuspruch für ein zentrales österreichisches SDG-OOP-Look&Feel.
[26]

Zusätzlich zu den Ergebnissen der konkreten Fragen wurden von den beteiligten Expert:innen auch viele zusätzliche Informationen bekanntgegeben, die sie für die Umsetzung von SDG-OOP und des OOTS in Österreich (oder generell) als wichtig erachten. Auch diese, sehr individuellen, Anregungen sind für die Umsetzungen sehr wichtig und fließen in die weiteren Tätigkeiten ein.

6.

Literatur ^

Bundesgesetz über die Einrichtung und den Betrieb eines Unternehmensserviceportals (Unternehmensserviceportal­gesetz – USPG)

Costa Ines, CEF Stakeholder Management Office, DIGIT, European Commission: EU4Digital, Introduction to CEF eDelivery (Presentation from October 2020), online: https://eufordigital.eu/steeringcommittee2/images/resources/Afternoon_side_event_Virtual_eDelivery_study_visit_.pdf

Durchführungsverordnung (EU) 2022/1463 der Kommission vom 5. August 2022 zur Festlegung technischer und operativer Spezifikationen des technischen Systems für den grenzüberschreitenden automatisierten Austausch von Nachweisen und zur Anwendung des Grundsatzes der einmaligen Erfassung gemäß der Verordnung (EU) 2018/1724 des Europäischen Parlaments und des Rates

eCertis – EU Procurement Certification: Quick Start Guide (https://ec.europa.eu/tools/ecertis/assets/eCertisQuickGuidePublic_en.pdf)

Verordnung (EU) 2018/1724 des Europäischen Parlaments und des Rates vom 2. Oktober 2018 über die Einrichtung eines einheitlichen digitalen Zugangstors zu Informationen, Verfahren, Hilfs- und Problemlösungsdiensten und zur Änderung der Verordnung (EU) Nr. 1024/2012

Verordnung (EU) Nr. 910/2014 des Europäischen Parlaments und des Rates vom 23. Juli 2014 über elektronische Identifizierung und Vertrauensdienste für elektronische Transaktionen im Binnenmarkt und zur Aufhebung der Richtlinie 1999/93/EG

  1. 1 Aus dem Titel der Single Digital Gateway Verordnung (https://eur-lex.europa.eu/eli/reg/2018/1724/oj).
  2. 2 Zu den Grundlagen des Once Only Prinzips: https://en.wikipedia.org/wiki/Once-only_principle.
  3. 3 Aus Artikel 1 der Durchführungsverordnung zur SDGR – Once Only Technical System (https://eur-lex.europa.eu/eli/reg_impl/2022/1463/oj).
  4. 4 Diese Aufzählung ist nicht abschließend anzusehen. Für die Funktionsweise der Gemeinsamen Dienste gibt [2] in den Artikeln 4 bis 7 Auskunft.
  5. 5 Aus dem USPG, Paragraph 1(3).
  6. 6 Diese Arbeitsgruppen sind in Abschnitt 6 der Durchführungsverordnung definiert.
  7. 7 Die gestrichelt dargestellten Blöcke werden zur fakultativen Nutzung für die beiden wichtigen Beteiligten (Corner 1 und 4) als zentrale Shared Services angeboten; sie können die Funktionen jedoch auch selbst in ihre Systeme einbauen.
  8. 8 Siehe 4-Corner Model in einer Präsentation der EK zu CEF eDelivery Building Block aus 2020 (Costa Ines, Folien 14 und 15) – die früheren CEF-Building-Blocks sind nunmehr Digital-Europe-Building-Blocks.
  9. 9 Die vier Ecken gemäß dem 4-Corner-Model sind in der obigen Grafik explizit eingezeichnet.
  10. 10 Dieses System der Nachweis-Beschreibungen wurde aus dem europäischen eCertis-System übernommen.
  11. 11 Siehe eIDAS-Verordnung, Artikel 44.
  12. 12 Verweis auf Durchführungsverordnung (Erwägungsgrund 20): Elektronische Identifizierungsmittel, die im Rahmen von elektronischen Identifizierungssystemen ausgestellt werden und gemäß der genannten Verordnung notifiziert wurden, sollten daher von Nachweise anfordernden Behörden verwendet werden, um die Identität eines Nutzers zu authentifizieren, bevor der Nutzer ausdrücklich die Nutzung des OOTS beantragt.
  13. 13 Das OOP der SDG übernahm vom europäischen eCertis-System (https://ec.europa.eu/tools/ecertis/#/homePage) den „kriterienbasierenden“ Ansatz. Hierbei werden nicht konkrete „Dokumente“ als Nachweise als solche angefragt, sondern auf bestimmte Kriterien (z.B. „Beweis der Geburt eines Individuums“) Nachweistypen gemappt, hinter denen wiederum die konkreten Nachweise zugeordnet sind. Das eCertis-System entspringt den Vorgaben der Europäischen Union zum Thema des „Beschaffungswesens“. Dieses System kommt der bestehenden Vielfalt der bei europäischen Behörden ausgestellten Nachweisen besser entgegen.
  14. 14 Siehe hierzu Artikel 8 der Durchführungsverordnung.
  15. 15 Insgesamt wurden daraus 12 Antworten sowohl aus der Sicht der Verfahrensportale wie auch der Datendienste erhalten. Sowohl bei den „Sichten“ des Verfahrensportals wie auch der Datendienste gab es je drei Enthaltungen.
  16. 16 Score: Gewichtet mit 3 Punkte für Erstreihung, 2 Punkte für Zweitreihung, 1 Punkt für Drittreihung und 0 Punkte für Viertreihung. Daraus wurde die Summe errechnet. Die Zahl in den eckigen Klammern bei der Ergebnisdarstellung geben die oben dargestellten Varianten wieder.