Jusletter IT

In Beiträgen der letzten beiden Jahre wurde die Single Digital Gateway Verordnung (SDGR) in umfassendem Maße dargestellt; diesbezüglich wird auf diese Artikel verwiesen.¹ In Kurzform soll an dieser Stelle dargestellt werden, dass sie ein „europäisches Gesetz“ darstellt, das „...die Einrichtung eines einheitlichen digitalen Zugangstors zu Informationen, Verfahren, Hilfs- und Problemlösungsdiensten...“ beinhaltet.² Im Artikel 14 der SDGR findet sich das Once Only Prinzip³ (SDG-OOP) definiert, in dem der automatisierte Austausch von Nachweisen zwischen Mitgliedstaaten geregelt ist.

Gegenständlicher Artikel umfasst eine Rückschau auf die Projektumsetzung und die spezifischen neuen Herausforderungen, die in der Umsetzung hervorgetreten sind, oder neuartige Muster von E-Government-Lösungen aufzeigten und erforderlich machten.

Beim bisherigen E-Government waren hauptsächlich nationale technische Infrastrukturen und Stakeholder bei einer Umweltanalyse zu berücksichtigen, im Gegensatz zur Umsetzung des OOTS der SDGR, mit nationalen Beteiligten und Beteiligten aus der Europäischen Union. Darüber hinaus ist die Umsetzung unabhängig von der Landesgröße bestimmt durch Komplexität der bestehenden E-Government-Services, Verwebungsgrad unterschiedlicher IT-Services, Restriktivität nationaler Regelungen und Erwartungen zum Datenschutz, als auch bestehenden Verordnungen und Richtlinien, wie auch parallel in Umsetzung oder Verhandlung befindlichen Verordnungen und Richtlinien der Europäischen Union.

Diese Faktoren bei der Umsetzung spiegeln sich in den Stakeholdern und Prozessen wider und müssen im Gesamten und in Abhängigkeiten betrachtet werden. Dadurch ergibt sich in der Organisation und bei Prozessen eine Vielzahl von Verzweigungen, die wiederum bei der Anwender:innen-Führung und Benutzererfahrung erheblichen Einfluss haben, als auch beim Beweis von Anforderungen von Behörden aus EU-Mitgliedstaaten. Gleichermaßen müssen bei der Erstellung von Anforderungen nationaler Verfahren bereits existierende Anforderungen in Betracht gezogen werden, Rückmeldungen von anderen EU-Mitgliedstaaten als auch Ergebnisse aus der Arbeitsgruppe selbst. Diese Vielzahl von Faktoren und Stakeholdern kann nur durch neue einheitliche standardisierte Prozesse in der Kommunikation, Erhebung, Erstellung von Nachweisanforderungen und Beleg von Nachweisanforderungen erfüllt werden.

Überdies sind neben fachlichen Bereichen auch organisatorische Maßnahmen im technischen Bereich notwendig, die alle Beteiligten im Systemverbund betrachten. Dies ist ebenfalls innerstaatlich, beginnend bei dem nationalen OOTS, über Verfahren und Datendienste bis hin zu den Gemeinsamen Diensten der Europäischen Kommission in Betracht zu ziehen und erfordert die Organisation eine Kette von Abhängigkeiten und Datenübertragen, die bisher im E-Government, wenn überhaupt, nur in weniger komplexem Ausmaß gewichtet werden mussten.

All die angeführten Wechselbeziehungen und Verflechtungen müssen nicht nur in der Umsetzung per se organisatorischen Prozessen unterlegt werden, sondern auch bei der Verwendung des OOTS durch Anwender:innen, insbesondere bei Hilfestellungen durch eine Betriebsorganisation.

Die Ziele der EU liegen in einem gemeinsamen Wirtschaftsraum, der auch die digitale Welt, und hier auch den spezifischen Bereich des E-Government umfasst. Durch die rezenten rechtlichen Vorschriften wird ersichtlich, dass das Prinzip der Interoperabilität hervorgehoben wird und grundsätzlich grenzüberschreitend gedacht wird. Programme, wie ISA2⁴ und das Interoperability Framework der Kommission (EIF)⁵, oder rechtliche Regelungen, wie die gegenständliche SDGR, aber auch eIDAS-Verordnung, bis hin zum Interoperable Europe Act (und andere) stellen dieses Prinzip immer voran.

Neben dem Rechtsrahmen für Interoperabilität sind die technischen Systeme in den europäischen Mitgliedstaaten, und damit auch die technischen Grundlagen für Interoperabilität, in vielen Fällen noch nicht auf eine vollständige Interoperabilität ausgelegt. Auch in neuen Vorhaben, wie die Umsetzung des SDG-OOP in der SDGR stellen sich diese Herausforderungen.

Die Umsetzung des technischen Systems des OOTS hat hier viele Sichten einzunehmen, weil bestehende Prozesse der Verwaltung elektronisch umfasst werden mussten. Dabei lagen die Herausforderungen natürlich vor allem in der rechtlichen „Compliance“, jedoch auch in der „systemischen“ zum gleichen Maße. Einerseits musste das OOTS derart umgesetzt werden, dass nationale technische Systeme, vor allem Verfahrensportale und Datendienste, mit den Herausforderungen umgehen konnten, zudem aber auch auf supranationaler Ebene das Zusammenspiel mit eIDAS-Identifikationen (und –Vertrauensdiensten), oder bestehenden Infrastruktur-Systemen, wie BRIS, EESSI, EUCARIS oder ähnliche.

In die technischen Prozesse des OOTS, sowohl national wie auch europäisch gedacht, fließen viele Konzepte zusammen, die zu einem global technischen, wie auch Anwender:innen-funktional spezifischen Funktionieren ineinandergreifen müssen. Eine Auswahl davon wird im Folgenden dargestellt werden.

Das österreichische OOTS stellt einen Systemverbund dar, der sowohl im internen Bereich eine signifikant hohe Komplexität in unterschiedlichen Domänen aufweist, zusätzlich aber auch auf mehreren Ebenen interoperabel mit externen technischen und organisatorischen Umwelten interagieren muss. Einerseits ist die Nutzung der eIDAS-Identifikation (über ID Austria) ein integraler Bestandteil der Umsetzung, andererseits haben wir mit dadeX/RSV⁶ eine nationale Basiskomponente als zentrale Datendrehscheibe integriert. Weitere interessante Herausforderungen ergaben sich aus den technischen (und auch organisatorischen) Serviceleistungen gegenüber den beiden Umwelten der Verfahrensportale (als Evidenz Requester) und der Datendienste (als Evidenz Provider), auf die im Speziellen in den folgenden Ausführungen eingegangen wird.

Abbildung 1: Überblick über die Systembereiche im Systemverbund des OOTS in Österreich

In der österreichischen Verwaltung gibt es, ähnlich wie in der Europäischen Union, eine Vielfalt an Herangehensweisen und Methoden, denen das zu erstellende System gerecht werden muss.

Ad Verfahrensportale:

Konkret gibt es bei der Architektur des österreichischen OOTS die Notwendigkeit, dass österreichische Verfahrensportale die Intermediäre Plattform auf zwei Arten benutzen können:

(i) Übergabe der Anwender:in an eine Komponente für Online Dialoge in der Intermediären Plattform (siehe oben in der Grafik, DIALOG Plattform, im Folgenden kurz DIALOG) und Rückkehr der Anwender:in mit den aus anderen Mitgliedstaaten erhaltenen Nachweisen, und

(ii) keinerlei Übergabe der Anwender:in, weil alle interaktiven Vorgänge im Verfahrensportal passieren.

In (i) und (ii) führt die Intermediäre Plattform sämtliche Kommunikationsprozesse mit Common Services und den Systemen von OOTS in anderen Mitgliedstaaten durch. Dies inkludiert die Kommunikationsprozesse des OOTS (SDG Request und Response); kryptografische Absicherung der Kommunikation im Zuge von eDelivery⁷; Abfrage, Caching, und Interpretation der Common Services der EK und fallweise der Common Services anderer Mitgliedstaaten; sowie Logging und Protokollierung.

In (i) übernimmt die Intermediäre Plattform mithilfe von DIALOG zusätzlich die gesamte Anwender:innen-Interaktion, die in OOTS notwendig ist. Dies ermöglicht eine sehr niederschwellige Verwendung des Systemverbundes. Die Bereitstellung von DIALOG als Shared Service und damit verbundene Herausforderungen und Vorteile werden in 3.4. thematisiert.

Ad Datendienste:

Zusätzlich zu diesen zwei Hauptvarianten der Verwendung der österreichischen Intermediären Plattform durch Verfahrensportale gibt es noch den Aspekt der Datendienste, für die ebenfalls verschiedene Varianten der Anbindung in Frage kommen. Bedingt durch Notwendigkeiten des Datenschutzes sind beispielsweise je nach Datendienst verschiedene Informationen über die Nachweise anfordernde Behörde im anfragenden Mitgliedstaat bis zum Datendienst weiterzuleiten. Bei strukturierten Nachweisdokumenten erlauben manche österreichischen Stakeholder aus Architekturgründen keine Filterung der Daten in der Intermediären Plattform; die Nachweise müssen deshalb direkt im Datendienst erstellt werden. Bei unstrukturierten Nachweisdokumenten (derzeit nur PDF Dokumente) gibt es die Herausforderung, wer für die Erstellung der Visualisierung von Nachweisdaten organisatorisch und technisch verantwortlich ist. Auf jeden Fall muss die Kompatibilität von Visualisierung und Datenformat durch internationale Standards sichergestellt werden. Die sogenannten OOTS Datenmodelle (die derzeit noch nicht definiert sind) sind eine Ausnahme, weil diese per Definition nur strukturiert übertragen und nicht visualisiert werden, und deshalb die Verantwortung per Definition bei der Nachweise anfordernden Behörde liegt.⁸

Ein zentraler Aspekt für eine erfolgreiche Umsetzung des OOTS ist die Identifikation von Nachweisarten aus anderen Mitgliedstaaten, welche für ein SDG-Verfahren verwendet werden können. Diese Identifikation kann allerdings aus mehreren Gründen nicht rein auf Basis der Namen der verwendeten Nachweisdokumente geschehen:

1. Möglicherweise gleiche Dokumente haben potentiell unterschiedliche Namen in verschiedenen Mitgliedstaaten;
2. Dokumente mit gleichem oder ähnlichem Namen in verschiedenen Mitgliedstaaten enthalten nicht notwendigerweise dieselben Informationen (bspw. enthalten österreichische Geburtsurkunden auch akademische Grade, deutsche Geburtsurkunden jedoch nicht);
3. Zu einigen Dokumenten gibt es potentiell schlicht keine Entsprechung in manchen Mitgliedstaaten (bspw. ist in Spanien das Konzept des Haushalts nicht in Verwendung, somit gibt es auch kein Dokument, welches einer Haushaltsbestätigung entsprechen würde).

Um dennoch eine grenzüberschreitende Zuordnung von Nachweisarten zu Nachweisanforderungen zu ermöglichen, wird im Rahmen des SDG OOTS ein u.a. auf das im Vergabebereich verwendete Tool eCertis⁹ zurückgehender abstrakter Ansatz verfolgt.¹⁰ In diesem werden die Nachweisanforderungen abstrakt als die benötigten Informationen oder auch die zu belegenden Kriterien modelliert. Diesen abstrakten Nachweisanforderungen werden seitens der Mitgliedstaaten Nachweisarten zugeordnet, welche die benötigten Informationen enthalten bzw. die Erfüllung der geforderten Kriterien belegen. So werden beispielsweise in der Nachweisanforderung Proof of existence of a legal person Informationen bezüglich des offiziellen Namens einer juristischen Person, Bestätigung deren Existenz, sowie Informationen bezüglich der Hauptanteilseigner (bspw. Name, Vorname, Geburtsdatum für natürliche Personen) gefordert. Derartige Informationen können bspw. durch den österreichischen Firmenbuchauszug oder den deutschen Handelsregisterauszug belegt werden, so dass diese beiden Nachweisarten der Nachweisanforderung zugeordnet werden könnten. Eine derartige Zuordnung ist im allgemeinen abhängig von einer möglichst eindeutigen Formulierung der Nachweisanforderungen. Zu diesem Zweck wird auf europäischer Ebene im Rahmen der SDG Arbeitsgruppen eine auf existierenden Vokabularen und Systemen (bspw. CORE Vocabularies¹¹, EMREX/ELMO¹² oder EUCARIS¹³) basierende formale Beschreibungssprache entwickelt. Die anfänglich im Fokus liegenden benötigten Namen für Informationen wie Geburtsort oder Adresse (oder dergleichen) bilden in Folge die Basis zur Formulierung komplexer Kriterien wie: Person X ist zum Anfragezeitpunkt volljährig gemäß österreichischem Recht, wenn Person X Geburtsdatum Y hat und die Differenz zwischen Anfragezeitpunkt und Y mindestens 18 Jahre beträgt.

Eine derartige abstrakte Formulierung der Nachweisanforderungen von Verwaltungsverfahren setzt sowohl neue organisatorische Abläufe als auch ein gewisses Umdenken auf Seiten der nachweisanfordernden Behörden voraus. Insbesondere müssen bislang teilweise dokumentenbasierte Anforderungen (bspw.: Folgende Dokumente sind dem Antrag beizulegen: ...) in abstrakte Anforderungen bezüglich der benötigten Informationen bzw. der zu belegenden Kriterien umformuliert werden. Ebenso müssen in Folge die formulierten Nachweisanforderungen auf europäischer Ebene eingebracht und gegebenenfalls hinsichtlich einer eindeutigen Formulierung mit den relevanten Stakeholdern der anderen Mitgliedstaaten diskutiert werden. Schließlich müssen seitens der nachweisbereitstellenden Behörden verfügbare und passende Nachweise identifiziert und den Nachweisanforderungen zugeordnet werden. Zur Unterstützung der Behörden bei allen Schritten dieses Prozesses von der Formulierung der Nachweisanforderungen bis zur Zuordnung der Nachweise wurde im Bundesministerium für Finanzen eine zentrale Supportstelle eingerichtet.

Eine abstrakte Formulierung der Nachweisanforderungen von Verwaltungsverfahren, wie sie im Rahmen des OOTS eingeführt wird, bietet weitreichende Potentiale auch abseits des Zweckes der Vermittlung von Nachweisarten. Potentiale auf nationaler Ebene beinhalten beispielsweise:

• Die zur Formulierung der Nachweisanforderungen notwendige Analyse der Verwaltungsverfahren kann zu deren Vereinfachung beitragen: Die Identifikation der benötigten Informationen (anstelle der verwendeten Dokumente) erlaubt eine Identifikation relevanter Verwaltungsregister zum Zwecke der direkten Datenübertragung in das Verfahren, sowie gegebenenfalls die Identifikation einer geringeren Anzahl von Dokumenten, welche die benötigten Informationen enthalten. Beides trägt zur Reduzierung der seitens der Anwender:innen beizubringenden Nachweise bei.
• Die im Rahmen der Zuordnung der Nachweisarten zu Nachweisanforderungen ermittelten Informationen können zu einer besseren Übersicht der österreichischen Verfahrens- und Registerlandschaft beitragen.

Potentiale auf europäischer Ebene beinhalten insbesondere:

• Der im Rahmen des SDG OOTS (weiter-)entwickelte Mechanismus bietet eine Blaupause zur allgemeineren Identifikation benötigter Daten aus anderen Mitgliedstaaten und kann somit übergeordnet von Relevanz sein.
• Die Analyse der Nachweisanforderungen und verfügbaren Nachweisarten auf Ebene der benötigten Informationsfelder ist ein Treiber für die weitergehende Harmonisierung der auszutauschenden Datenmodelle, da anhand einer formalen Darstellung einfacher die Gemeinsamkeiten und Unterschiede der in den Mitgliedstaaten verwendeten Datenmodelle bzw. Dokumente ermittelt werden können. Dies ist weiterhin die Grundlage für einen Austausch der Daten direkt in den Verfahren mit dem Ziel, dass weniger Nachweise durch die Anwender:innen selber bereitgestellt werden müssen.
• Die formale Formulierung der zu erfüllenden Kriterien kann zur Datenminimierung beitragen, da die Berechnung, ob ein Kriterium (auch Requirement genannt) erfüllt ist, auf die Seite der datenbereitstellenden Stellen ausgelagert wird (wo rechtlich möglich). Somit muss bspw. nur noch eine ja/nein-Antwort auf die (formale) Frage der Volljährigkeit oder Straffreiheit zwischen den Behörden übermittelt werden, und nicht mehr das genaue Geburtsdatum bzw. die Liste der Vorstrafen. Eine formale Beschreibungssprache für die Kriterien mit einer standardisierten Semantik ermöglicht hierbei die transparente, belegbare und vorhersehbare Auswertung auf Seiten der datenbereitstellenden Stellen.

Zur Unterstützung des Datenhandlings und für die Ermöglichung transparenter und nachvollziehbarer Berechnungen und Herleitungen steht in der Architektur des österreichischen IT-Systemverbunds des OOTS die Reasoning-Komponente REAS zur Verfügung. Hierbei handelt es sich um eine generische technische Schlussfolgerungs-Anwendung, welche die in einer separaten Wissensdatenbank, dem Repräsentationspeicher (RESP), gespeicherten Regeln anwenden, verketten und auswerten kann. Auf technischer Ebene basiert die Komponente auf stratifiziertem Datalog als Regelsprache, wobei das standardisierte Format RuleML für die Regeln verwendet wird. Die logikbasierte Regelsprache ermöglicht hierbei transparente und nachvollziehbare Berechnungen, während das standardisierte Regelaustauschformat eine größtmögliche Flexibilität und Herstellerunabhängigkeit sicherstellt. Einsatzgebiete der Komponente REAS beinhalten unter anderem die Parametrisierung der in der Intermediäre Plattform auszuführenden Prozesse in Abhängigkeit von der eingehenden Anfrage.

Aufgrund der generischen Charakteristik der Komponente kann diese jedoch auch für vielfältige weitere Aufgaben verwendet werden. Geplante Verwendungsgebiete beinhalten insbesondere Funktionalitäten für die Unterstützung der zuständigen Behörden im Prozess der Definition von Nachweisanforderungen sowie der Identifikation relevanter Nachweise und deren Zuordnung zu Nachweisanforderungen. Aufbauend auf der strukturierten Darstellung der Nachweisanforderungen und auf bereits erfolgten Zuordnungen von Nachweisen mit den entsprechenden Datendiensten können beispielsweise für eine neu hinzugekommene Nachweisanforderung potentiell bereits verfügbare Nachweise mit den benötigten Informationen oder auch entsprechende Datendienste vorgeschlagen werden. Weiter kann der Prozess der Definition von Nachweisanforderungen unterstützt werden, indem zu teilweise definierten Nachweisanforderungen verwandte und bereits existierende Nachweisanforderungen dargestellt werden.

Prinzipiell ermöglicht die Reasoning-Komponente auch die transparente und nachvollziehbare Transformation der zu übermittelnden Daten gemäß Vorgaben und im Auftrag der datenbereitstellenden Stellen. Somit könnten beispielsweise in Zukunft Nachweisanforderungen in Form von Ja/Nein-Kriterien nachvollziehbar und standardisiert auf Wunsch und im Auftrag der Datendienste ausgewertet werden, und nur noch das Ergebnis an den anfragenden Mitgliedstaat übermittelt werden. Während dies sicherlich im Sinne der Datenminimierung wäre ist anzumerken, dass derzeit auf europäischer Ebene noch keine Nachweisanforderungen in Form von formal auswertbaren Ja/Nein-Kriterien vorliegen. Die Definition einer formalen Sprache, welche die Formulierung derartiger Kriterien ermöglicht, ist eine der Aufgaben der Arbeitsgruppe für Evidence Mapping und derzeit noch in Arbeit.¹⁴ Neben dem Umdenken von einem dokumentenbasierten zu einem informationsbasierten Ansatz sind hierfür auf Seiten der nachweisanfragenden Behörden potentiell auch Änderungen der gesetzlichen Grundlagen notwendig.

Schließlich können potentiell auch über die Inhalte in den europäischen Common Services hinausgehende Daten in Form von Regeln im Repräsentationsspeicher RESP hinterlegt werden, und über die Reasoning-Komponente in alle Richtungen abfragbar gemacht werden. Dies ermöglicht beispielsweise die Verwendung für über die von der SDG-Verordnung umfassten Verfahren hinausgehende nationale Use-Cases, bei denen REAS und RESP die Funktion eines „nationalen Evidence Broker / Data Service Directory“ für Nachweisanforderungen bzw. Nachweise übernehmen können, die rein national (bspw. zwischen verschiedenen Bundesländern) vermittelt werden sollen.

Bei der Umsetzung von SDG OOTS in Österreich wurde DIALOG als Shared Service konzipiert und umgesetzt. Bei der Erstellung von DIALOG gab es mehrere Herausforderungen und Entscheidungen, die im Folgenden thematisiert werden.

Ad Verfahrensportale:

Die Nutzung von DIALOG auf Seite der Verfahrensportale ist optional. Eine Nutzung bietet den Vorteil, dass nur sehr wenige SDG OOTS-spezifische Dialoge im Verfahren umgesetzt werden müssen, und dass die Verwendung von SDG OOTS uniformer wird: es wird für Anwender:innen einfacher, sich in der komplexen Thematik von SDG OOTS zurecht zu finden, umso öfter in verschiedenen Verfahren DIALOG verwendet wird. In einer Erhebung wurde ermittelt, dass manche Verfahrensportale DIALOG nutzen wollen, andere wollen die Anwender:innen-Interaktion selber definieren.

Die wichtigsten Herausforderungen bei der Erstellung von DIALOG für die Seite der Verfahrensportale (Evidence Requester Seite) sind:

(i) die User Experience für die Entscheidung, ob überhaupt SDG OOTS verwendet werden soll,

(ii) die User Experience für die Ermittlung der Nachweisarten und Datendienste, und

(iii) die User Experience für die Behandlung mehrerer Kriterien in einem Verfahren.

Ad General Request:

Bei Punkt (i) besteht in einem Verfahren die Frage, ob OOTS einen Mehrwert bringt, also ob zu den Kriterien des Verfahrens auch Nachweise in dem Mitgliedstaat existieren, der für die jeweiligen Anwender:in relevant ist. Dafür wurde in Kooperation mit den Verfahrensportalen der sogenannte General Request eingeführt. Der General Request ermöglicht es, vor Nutzung von DIALOG festzustellen, welche Mitgliedstaaten zu einem bestimmten Kriterium eine Nachweisart bereitstellen. Dadurch kann die Anwender:in für jedes Kriterium entscheiden, ob das OOTS für die Erbringung des Nachweises verwendet werden soll, oder nicht. Der Vorteil dieser „Vorentscheidung“ ist, dass keine Frustration entsteht, wenn die Anwender:in für ein Kriterium in DIALOG navigiert, sich dort zurechtfinden muss, um potentiell festzustellen, dass gar kein Nachweis verfügbar sein kann, weil in den jeweils relevanten Mitgliedstaaten noch kein passender Nachweis hinterlegt wurde.

Ad Common Services Abfrage:

Bei Aspekt (ii) geht es um die dreistufige Auswahl der Nachweisarten und Datendienste für jedes Kriterium, genannt „Common Services Abfrage“. Für jedes Kriterium (fiktives Beispiel „Nachweis des Universitätsabschlusses auf Bachelor-Level“) wird zuerst der Mitgliedstaat ausgewählt, aus dem passende Nachweise angefordert werden sollen. Danach wird aus der Liste der zugeordneten Nachweisarten ein Element ausgewählt (fiktive Beispiele „Bachelorzeugnis DE“ oder „Bakkalaureatsurkunde AT“). Wichtig ist hier, dass ein Mitgliedstaat auch mehrere Nachweisarten in Kombination für den Nachweis eines Kriteriums definieren kann (fiktives Beispiel „Bachelorstudienzeugnis und Bachelorprüfungszeugnis“). Für jede Nachweisart, die an diesem Punkt ausgewählt wurde, gilt es nun in einem dritten Schritt, den passenden Datendienst auszuwählen (fiktives Beispiel „Technische Universität Wien“ oder „Universität Wien“). Die Erstellung der Interaktionsmöglichkeiten bei den Online Dialogen für Anwender:innen für diese Auswahlvorgänge benötigte mehrere Iterationen von Mockups und Feedbackrunden, sowohl mit Personen, die sich in SDG OOTS gut auskennen, als auch mit Personen, die noch nie etwas damit zu tun hatten.

Ad Mehrfache Kriterien in einem Verfahren:

In Punkt (iii) geht es darum, dass in herkömmlichen Verwaltungsverfahren mehrere Beilagen beigebracht werden müssen. Analog dazu werden in einer Sitzung oftmals mehrere Kriterien existieren, die alle erfüllt werden müssen, um das Verfahren durchzuführen. Aus Sicht der Intermediäre Plattform gibt es verschiedene Möglichkeiten, dies zu handhaben:

(a) alle Kriterien werden zu Beginn an DIALOG übergeben und zunächst muss die Anwender:in für sämtliche Kriterien die passenden Mitgliedstaaten, Nachweisarten, und Datendienste auswählen, und danach erfolgt die Zustimmung zur Datenübertragung und die Weiterleitung für die Vorschau ins Ausland; oder aber

(b) das Verfahren sendet die Anwender:in für das erste Kriterium in DIALOG, in der dieses Kriterium behandelt wird, und zu einem späteren Zeitpunkt wird die Anwender:in erneut für ein anderes Kriterium DIALOG geschickt. Dies passiert so lange, bis alle Kriterien abgedeckt wurden.

Ein sehr wesentlicher Punkt bei (b) ist, dass die Anwender:in sich nicht für jedes Kriterium neu einloggen muss, ansonsten führt (b) zu unnötiger Frustration. In der österreichischen Intermediären Plattform sind beide Varianten möglich, und in Variante (b) ist kein erneuter Login notwendig, solange die Zeitspanne zwischen der Bearbeitung beider Kriterien ausreichend kurz ist.

Eine zusätzliche Herausforderung, die orthogonal zu den obigen Überlegungen gehandhabt werden muss, ist die mehrfache Verwendung des selben Kriteriums in einer Sitzung: es ist denkbar, dass ein Kriterium aus mehreren Mitgliedstaaten mit unterschiedlichen Nachweisen erbringbar ist, und es ist denkbar, dass die Anwender:in mehrere dieser Nachweise gleichzeitig erbringen will oder muss, beispielsweise im Fall von Universitätsabschlüssen oder Praxisnachweisen (wo die Summe der Praxiszeiten einen gewissen Schwellenwert überschreiten muss). Die mehrfache Verwendung eines Kriteriums ist in der österreichischen Intermediären Plattform geplant, und zwar so, dass die Anwender:in für jedes Kriterium frei wählen kann, dieses mehrfach zu erbringen.

Ad Datendienste:

Die Nutzung von DIALOG auf Seite der Datendienste wurde in Österreich als Standard definiert: es ist nicht möglich, dass ein Datendienst ein eigenes Preview zur Verfügung stellt. Dies wurde in einer Erhebung von Seiten der Datendienste nicht erwünscht, weil das einen wesentlichen Mehraufwand für die Datendienste verursachen würde.

Die hauptsächliche Herausforderung von DIALOG auf Seite der Datendienste ist der Umgang mit mehreren Anfragen derselben Evidence Requester Session. Es ist technisch nicht vorgeschrieben, ob Anfragen für mehrere Nachweisdokumente an einen Mitgliedstaat gleichzeitig (alle Anfragen, danach wird die Anwender:in ins Preview geschickt) oder sequentiell (Anfrage, dann Anwender:in im Preview, dann nächste Anfrage, dann kommt erneut die Anwender:in ins Preview) stattfinden sollen. Nachdem dies durch die anfragende Seite bestimmt wird und somit außerhalb der Kontrolle von DIALOG liegt, behandeln wir mehrfache Dokumentenanfragen in einer Session folgendermaßen: die Anwender:in kann in DIALOG immer nur das Preview für genau eine Nachweisanfrage behandeln, allerdings ist es für alle Nachweisanfragen einer Session nur einmal notwendig, sich per eID einzuloggen. Dies macht zwar eine separate Navigation zwischen Evidence Requester und DIALOG für jedes Preview notwendig, allerdings werden so zwei wesentlichen Probleme verhindert: (i) die Komplexität einer User Experience, in der jederzeit eine zusätzliche Anfrage hinzukommen kann, und angezeigt und bearbeitet werden muss, und (ii) die Gefahr von Zeitüberschreitungen bei Anfragen die von weiteren Anfragen gefolgt werden, wodurch die Anwender:in unerwartet lange im Preview verbleiben könnte. Insgesamt erwarten wir durch die sequentielle Bearbeitung von Nachweisanfragen ein wesentlich robusteres Gesamtsystem als würden wir mehrere Nachweisarten in einem Preview handhaben.

Es ist wichtig zu erwähnen, dass ein herausforderndes Zusammenspiel vieler Initiativen meist auf den Schultern von Vorarbeiten steht. Einerseits sind hier die gesetzlichen Grundlagen generell zu erwähnen; im technischen Bereich, von Anforderungsanalyse bis hin zur Testung nach der Implementierung, sind zusätzlich die Erfahrungen von begleitenden Initiativen essentiell, welche im europäischen Bereich oftmals auch von europäischen Projekten abstammen. In diesem Zusammenhang sollen die technischen Konzepte aus der Forschung der beiden großen EU-Projekte TOOP¹⁵ und DE4A¹⁶ explizit hervorgehoben werden.

Während TOOP für die Umsetzung der Kernanwendungen von OOTS und das generelle Verständnis einer derartigen grenzüberschreitenden Anwendung von großer Bedeutung war, war zudem der Erfahrungsgewinn aus der Testung der entwickelten Pilot-Anwendungen im Rahmen von sogenannten Connectathons ein unschätzbarer Gewinn, der sich in den Projectathons¹⁷ bei der Umsetzung des OOTS sehr bezahlt gemacht hat.

Im etwas späteren EU-Projekt DE4A wurden wiederum wichtige Erkenntnisse in den Bereichen der technischen Umsetzung von Semantik, wie auch der Einbindung von Trust Systemen ausgearbeitet, die ihrerseits in den rechtlichen Grundlagen Einzug fanden, und zudem ein großes Verständnis für diese Herausforderungen mit sich brachten.

SDG-OOP und das damit einhergehende OOTS stehen mit 12.12.2023 an einem Startpunkt, der ein kontinuierliches Wachsen vor allem der konkreten Inhalte (Nachweise) mit sich bringen wird. Aus den kommenden Erfahrungen wird sich zeigen, welche Erfahrungen aus den neuen Methoden für grenzüberschreitendes E-Government gezogen werden können. Ein wichtiger Punkt hierbei wird die Akzeptanz durch Anwender:innen sein, die letztendlich die wichtigste Instanz im Gesamtsystem sind und deren Nutzen aus SDG-OOP und dem dahinterliegenden OOTS ein wichtiger Erfolgsindikator darstellt.

Bundesgesetz über die Einrichtung und den Betrieb eines Unternehmensserviceportals (Unternehmensserviceportalgesetz – USPG)

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)

Once Only Hub, Once-Only Technical System Projectathon Participant Playbook v3.00 (Once-Only_Technical_System_Projectathon_Playbook_v3.00.pdf)

Piswanger Carl-Markus, Suchow Olga, Nesslinger Georg, Helger Philip, Das europäische Forschungsprojekt DE4A. Überblick über die österreichische Beteiligung und den Einfluss des Projekts auf die Umsetzung der SDG-Verordnung, IRIS 2022

Piswanger Carl-Markus, Plank Felix, Lellmann Björn, Once Only Prinzip in der Single Digital Gateway Verordnung – Status und Erkenntnisse, IRIS 2023

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