Technische Bestandteile von EfA-Leistungen

Der Kern des Modells EfA aus technischer Sicht ist, dass ein Land den Online-Dienst zentral entwickelt und auch zentral betreibt. Dabei muss sichergestellt werden, dass die Lösungen im umsetzenden und in den anschließenden Ländern aufeinander abgestimmt sind und der Anschluss an den zentral bereitgestellten Online-Dienst reibungslos gelingt. Hierfür sollte eine frühzeitige, enge und dauerhafte Einbindung der Fachakteure aller Bundesländer, insbesondere der relevanten Fachverfahrenshersteller, sichergestellt werden (siehe Fallbeispiel BAföG am Ende dieses Kapitels).


Um die Herausforderungen und Lösungsansätze bei der technischen Umsetzung von EfA-Leistungen näher zu verstehen, ist es hilfreich auf eine Denkschablone zurückzugreifen, die zwischen vier wesentlichen Architekturebenen differenziert: Den Portalen, dem Online-Dienst, den Basiskomponenten, und dem Backend mit den Fachverfahren und Registern (siehe Abbildung 100). Grundsätzlich werden in den weiteren Ausführungen die Prozesse und technischen Systeme zur Bearbeitung der Verwaltungsverfahren innerhalb der zuständigen Behörden nicht betrachtet. Der Fokus liegt ausschließlich auf den erforderlichen Schnittstellen. Die Datenverarbeitung und -prüfung in den Fachverfahren obliegt jedem einzelnen Land (AL und UL). So ist auch sichergestellt, dass durch die Umsetzung des Online-Dienstes im Modell EfA keine Kompetenzübertragung auf den Betreiber dieses Dienstes stattfindet (z.B. an den Bund oder ein UL).

Abbildung 100: Technische Bestandteile von EfA-Leistungen


Die Portale stellen sicher, dass die Leistungen für Nutzer:innen auffindbar sind und angesteuert werden können. Im Rahmen des Portalverbunds werden das zentrale Bundesportal sowie die Portale der Länder und Kommunen miteinander verknüpft.


Der eigentliche Online-Dienst bildet typischerweise die Antragsstrecke einer Verwaltungsleistung und die entsprechende Datenerhebung und -Verarbeitung ab, je nach Ausgestaltung des Dienstes können aber weitere Funktionalitäten auf dieser Ebene integriert sein. Technisch kann bei Bedarf durch sogenannte Mandanten sichergestellt werden, dass die Datenverarbeitung für die einzelnen Länder getrennt erfolgt.

Wichtige Querschnittsfunktionalitäten, die für alle oder zumindest viele OZG-Leistungen in ähnlicher Form benötigt werden, werden nicht für jede einzelne Leistung extra entwickelt. Stattdessen gibt es dafür gemeinsame Basiskomponenten. Diese werden teilweise bundesweit und teilweise innerhalb der Länder bereitgestellt und an die Online-Dienste nach Bedarf angeschlossen. Wichtige Basiskomponenten sind die Nutzerkonten und die ePayment-Funktionalität.


Die Basis- und Online-Dienste können dann über standardisierte Datenübermittlungswege an die dezentralen Fachverfahren und Register angeschlossen werden.


Das UL ist grundsätzlich für die Umsetzung des Online-Dienstes inklusive standardisierter Schnittstellen zu Fachverfahren und Basiskomponenten verantwortlich. UL und AL müssen jeweils im Backend die Schnittstellen in den jeweils genutzten Fachverfahren und Registern implementieren und einen geeigneten Zugang zum Online-Dienst für ihre Bürger:innen gewährleisten. Die dabei erforderlichen Schritte werden in den Kapiteln 10.2.2.3. und 10.2.3.3. jeweils näher erläutert.


Technische EfA-Mindestanforderungen

Bei der technischen Umsetzung von EfA-Diensten sind die länderübergreifende Koordination und die Einhaltung gemeinsamer Standards von besonderer Bedeutung. Vor diesem Hintergrund nehmen technische Aspekte erheblichen Raum in den EfA-Mindestanforderungen ein, auf deren Einhaltung sich die Länder selbst verpflichtet haben.


Die Anforderungen zielen hierbei bewusst ausschließlich auf etablierte Technologien und bestehende Infrastrukturen ab. Sofern sich im Rahmen der OZG-Umsetzung weitere Technologien durchsetzen werden, können diese in die Anforderungen aufgenommen werden.


Die definierten Mindestanforderungen decken 8 technische Dimensionen ab, die für die Umsetzung von EfA-Services von besonderer Relevanz sind: Oberflächengestaltung und Design, Fachlogik, Nutzerkonto, Payment, Datenaustauschstandard, Routing & Transport, rechtliche Nachnutzungsmöglichkeit und Organisation. Wo relevant, werden in der folgenden Aufbereitung die tabellarisch dargestellten Mindestanforderungen um vertiefende Erläuterungen ergänzt.

Oberflächengestaltung & Design

Nr. Anforderung
OD1Der Online-Dienst MUSS über ein neutrales (keine landes-, kommunal- oder behörden-spezifischen Styleguides oder die vollständige Anmutung der Oberfläche der jeweiligen Verwaltungsportale der beteiligten Länder, Kommunen oder Behörden) Design verfügen.
OD2Der Online-Dienst SOLL über ein mit Nutzer:innen getestetes Design verfügen und
die Leitlinien zum Nutzererlebnis Portalverbund berücksichtigen.
OD3Der Online-Dienst MUSS, nachdem das leistungsspezifische Zuständigkeitsmerkmal (z.B. Postleitzahl, Ortsangaben oder georeferenzierter Daten oder Parameterübergabe bei Online-Dienst-Aufruf) ermittelt wurde, die individuell zuständige Behörde mit den Kontaktdaten anzeigen und SOLL das jeweilige Wappen der zuständigen Gebietskörperschaft, sofern es durch diese hinterlegt wurde, anzeigen.
OD4Der Online-Dienst MUSS die für den Empfang des Antrags zuständige(n) Behörde(n) mittels Leistungsschlüssel gemäß FIM und amtlichen Regionalschlüssel aus dem aktuellen Datenbestand des Portalverbundes ermitteln können.

Fachlogik

Nr. Anforderung
F1Der Online-Dienst MUSS die fachrechtlichen Anforderungen der Bundesgesetze erfüllen.
F2Der Online-Dienst MUSS landesrechtliche Zusatzanforderungen aller nachnutzenden Länder berücksichtigen.
F3Der Online-Dienst SOLL bei Bedarf landes- oder satzungsrechtliche Ausführungsvorschriften zu bundesrechtlich geregelten Leistungen geeignet berücksichtigen können (z.B. durch Mandantenfähigkeit, Parametrisierung).


Die Datenmodellierung des Formulars umfasst insbesondere die in FIM-Notation11 beschriebenen Datenfelder der Formulare inklusive der Eingaberestriktionen und Abhängigkeitsregeln, die hierbei zu beachten sind, sowie die Nachweise. Diese sollten bei EfA-Leistungen möglichst einheitlich sein. Wenn überhaupt, sollten Anpassungen an individuelle Anforderungen, wie beispielsweise zusätzliche Datenfelder in einem Land, minimal sein. Generell sind landesspezifische Besonderheiten vor dem Hintergrund bundeseinheitlicher Rechtsgrundlagen allerdings zu hinterfragen. Weitergehende Anpassungen der fachlichen Formularlogik an individuelle Anforderungen von Ländern, Kommunen oder Behörden wären grundsätzlich möglich, erhöhen allerdings die Komplexität der Entwicklung und Pflege.


Bei der Entwicklung der Formularlogik müssen unbedingt Expert:innen des fachlichen Vollzugs der Leistungen, also Empfänger:innen der Formulardaten, mit einbezogen werden.


UL und AL müssen sich im Rahmen der Zusammenarbeit auf die fachliche Formularlogik verständigen sowie Strukturen und Mechanismen etablieren, in denen diese gepflegt und bei Bedarf fortgeschrieben werden, so bietet sich beispielsweise die jeweilige Arbeitsgruppe der zuständigen Fachministerkonferenz als Plattform zur Abstimmung von gesetzlichen Änderungen an.

Nutzerkonto

Nr. Anforderung
NK1An den Online-Dienst für Bürgerinnen und Bürger MUSS mindestens ein interoperables Nutzerkonto (Authentifizierung und Postfach) angebunden sein. Wenn ein Online-Dienst kein interoperables Nutzerkonto anbinden kann, dann muss die BundID angebunden werden.
NK2An den Online-Dienst für Unternehmen und andere Organisationen MUSS das einheitliche Organisationskonto angebunden werden.

Übergangsregelung zu NK2: Andere Organisationskontos, die dem Funktionsumfang der Bausteine 1-6 entsprechen, können bis zur vollständigen Verfügbarkeit des einheitlichen Organisationskontos Bausteine 1-6 weiter eingesetzt werden.


EfA-Leistungen stellen grundsätzlich keine besonderen Anforderungen an die Nutzerkonten der UL oder AL, da die Anmeldung künftig ohnehin durch Herstellung der Interoperabilität der Nutzerkonten von Bund und Ländern mit jedem Nutzerkonto bei jedem Online-Dienst möglich werden soll. Bis die Interoperabilität der Nutzerkonten hergestellt ist muss das Nutzerkonto Bund oder das einheitliche Unternehmenskonto angebunden werden. Die einzige Besonderheit ist, dass Nutzer:innen, die bislang noch nicht über ein Nutzerkonto verfügen, bei der Erst-Registrierung aktiv dahin geleitet werden sollten, das Nutzerkonto ihres Herkunftslandes einzurichten. Sofern zusätzlich Fachkonten erforderlich sein sollten, um in größerem Umfang Fachdaten zu speichern, wie beispielsweise für Verlängerungs- oder Änderungsanträge, sollten diese als Profile im Online-Dienst angelegt werden, an denen sich Nutzer:innen mit einem interoperablen Nutzerkonto anmelden.


Es bestehen unterschiedliche Möglichkeiten für die Umsetzung des Rückkanals, über den insbesondere der Bescheid bekannt gegeben werden soll – sofern einschlägig: Eine denkbare Option für die Bekanntgabe des Bescheids ist das Nutzerkonto-Postfach (siehe §9 OZG: Verwaltungsakt gilt am dritten Tag nach der Bereitstellung zum Abruf als bekannt gegeben) Eine andere Möglichkeit mit gegebenenfalls geringeren Anforderungen an die Interoperabilität des Rückkanals ist ein Zustelldienst. Dabei wird der Bescheid durch Land A online zum Abruf bereitgestellt und eine Benachrichtigung mit einer Verlinkung in das Nutzerkonto eingestellt. Nach Aufruf der URL wird die/der Nutzer:in authentifiziert und der Bescheid angezeigt. Das Fachverfahren wird über den Abruf benachrichtigt. Die beschriebenen Anforderungen gelten jedoch gleichermaßen für alle Online-Dienste und sind keine Besonderheiten von EfA-Leistungen. Falls individuelle Anpassungen der fachlichen Formularlogik erforderlich sind, sollte die/der LV des UL eine entsprechende Unterarbeitsgruppe bzw. ein Teilprojekt aufsetzen. Die betroffenen AL müssten eine aktive Mitwirkung sicherstellen. Alle anderen AL müssten mindestens die Ergebnisse überprüfen.

Payment

Nr. Anforderung
P1Wenn die fachliche Anforderung einer Vorabzahlung gegeben ist und die Berechnung einer Gebühr im Online-Dienst möglich ist, MUSS der Online-Dienst für die Bezahlung eine von den empfangenden Behörden bereitzustellende
Bezahlkomponente parametrisiert aufrufen können, sofern diese Komponente und deren Parameter (im PVOG und DVDV) von der empfangenden Behörde bereitgestellt werden. Dabei MUSS die standardisierte Bezahldienstschnittstelle (Payment-API) für die Anbindung verwendet werden, sobald die Payment-API mindestens in der Version 1 vorliegt.
P2Der Online-Dienst KANN zusätzlich eine eigene Bezahlkomponente anbieten, die Behörden konfigurieren können, die über keine eigene Bezahlkomponente verfügen.


Bei einigen Verwaltungsverfahren sind Gebühren fällig, wodurch für die digitale Abwicklung ein Bezahldienst erforderlich wird. Der Bezahldienst sollte im Regelfall nicht Bestandteil des EfA-Online-Dienstes selbst sein, sondern als landes- bzw. behördenspezifische Basiskomponente angebunden werden. Hintergrund ist, dass die Bezahldienste regelmäßig an die Haushalts- und Kassenverfahren angebunden und hierfür konfiguriert werden müssen, damit die Zahlungen korrekt zugeordnet und verbucht werden können. Bei der Umsetzung ist deshalb eine Weiterleitung auf dezentrale Payment-Dienste vorzusehen, bei denen die Gebühren entrichtet werden. Hierbei werden über einen Webservice die Gebührenhöhe und geeignete Identifikationsmerkmale an den Bezahldienst übergeben. Nutzer:innen sind solche Weiterleitungen an Zahlungsdienstleister im Rahmen von Bezahlvorgängen aus dem E-Business gewöhnt. Denkbar ist auch, dass den Nutzer:innen die Zahlungsaufforderung direkt von der zuständigen Behörde übermittelt wird, sobald die Antragsdaten dort eingegangen sind. Dies hat den Vorteil, dass grundsätzlich keine Anbindung zwischen der EfA-Leistung und dem dezentralen Bezahldienst erforderlich ist. Zudem ist diese Option vorzusehen: Gebühren für Verwaltungsverfahren können vor- oder nachgelagert fällig werden, zum Beispiel wenn die Gebührenhöhe erst im Rahmen der Antragsbearbeitung festgelegt wird. Ein Bezahldienst kann in Ausnahmefällen Bestandteil der EfA-Leistung sein, sofern bei einer Behörde beispielsweise kein solcher Dienst vorhanden ist und keine weiteren Gebühreneingänge verzeichnet werden.

Datenaustauschstandard

Nr. Anforderung
DS1Der Online-Dienst MUSS über eine automatisierte Schnittstelle die Antragsdaten in einem standardisierten XML-Format (z.B. als Modul innerhalb eines XÖV-Standards oder die XDatenfelder in einem XFall-Container) ausgeben, das von Fachverfahren wiederum (halb-) automatisch eingelesen werden kann. Sofern es keine Fachverfahren gibt, SOLL der Online-Dienst (zusätzlich) eine lesbare PDF-Datei erzeugen.
DS2Sofern kein Fachstandard existiert, MUSS ein Standardisierungsprozess aufgesetzt werden, der folgende Aspekte sicherstellen soll: Planbarkeit, Verlässlichkeit, Verbindlichkeit, Finanzierung; Steuerung durch die öffentliche Verwaltung; Beteiligung aller relevanten Stakeholder; Offenheit der Standards im Sinne der Free Software Foundation Europe (https://fsfe.org/freesoftware/standards/index.de.html); Praxisorientierung; regelmäßige Weiterentwicklung (Änderungsmanagement – nicht nur bei Änderungen der Rechtsgrundlagen, sondern auch aufgrund von
Feedback aus der Praxis); hoher Detaillierungsgrad, hohe Qualität, technisch robust; angemessener und realistischer Standardisierungsgegenstand; nachgewiesener Reifegrad der Methodik / des Rahmenwerks; angemessene Berücksichtigung der Vorgaben und Angebote der EU.
DS3Der Online-Dienst MUSS eine strukturierte Ausgabe des Antrags im XFall-Format basierend auf den zugehörigen FIM-Stammdatenschemata erzeugen, sofern in der Verwaltung KEIN Fachstandard existiert oder geschaffen wird (z.B. XÖV).
DS4Der Online-Dienst SOLL an die meist genutzten Fachverfahren unterschiedlicher Hersteller (soweit existent) in den nach dem EfA-Prinzip anzuschließenden Ländern anschlussfähig sein.


Die Anforderungen an die Standardisierung des Datenaustausches zwischen der EfA-Leistung und den beteiligten Stellen hängen maßgeblich von der Art und Form der IT-Unterstützung der weiteren Bearbeitung des Verwaltungsverfahrens innerhalb der Verwaltung ab. Wie in Anforderung DS1 deutlich wird, können in dieser Hinsicht zwei Szenarien unterschieden werden:

  1. Keine Fachverfahren oder geringe Fallzahlen: Keine automatisierte Schnittstelle notwendig; Übergabe der Antragsdaten per PDF im FIM-Datenschema (FIM-Format) des Antragsformulars; weitere manuelle Bearbeitung durch Sachbearbeiter:innen; ggf. halbautomatische Verarbeitung der PDF-Datei, wenn die Datenstruktur sehr einfach ist
  2. Fachverfahren und relevante Fallzahlen: Standard für automatisierte Schnittstelle notwendig; Übergabe der Antragsdaten grundsätzlich im standardisierten XML-Format unter Berücksichtigung der fachlichen Vorarbeit von FIM (Fachformat); weitere vollautomatische Bearbeitung durch ein Fachverfahren oder eine Landschaft unterschiedlicher Fachverfahren; das Fachformat regelt Sonderfälle, Multiplizitäten, fachliche Abhängigkeiten wie z. B. regelbasierte Pflichtfelder, verwendet geeignete Datentypen, spezifiziert Code-Listen, überträgt Kernkomponenten in einer standardisierten Struktur und Semantik (z. B. Namen natürlicher Personen im Format des Personenstandswesen, Anschriften im Format des Meldewesens), die eine Interoperabilität zu anderen Fachlichkeiten sicherstellen; hierbei besteht die Option einer Förderung eines klassischen XÖV-Projektes.

Die technische Übergabe der PDF-Datei im FIM-Format oder der XML-Daten im Fachformat an Sachbearbeiter:innen oder Fachverfahren wird im Abschnitt „Routing & Transport“ behandelt.


Die Bedarfe der Behörden, aber auch der IT-Dienstleister und Produkthersteller müssen bei der Entwicklung eines Standards beachtet werden. Es ist ein professionelles Vorgehen erforderlich, um die folgenden Anforderungen an den Standardisierungsprozess und an sein Ergebnis, den Datenaustauschstandard, sicherzustellen.


Sofern fachlich abgestimmte FIM-Stamminformationen vorliegen, es Fachverfahren mit ausreichend Fallzahlen gibt und für die vorliegende OZG-Leistung noch kein fachlicher Schnittstellenstandard existiert (XÖV-Standard oder anderer Fachstandard), wird ein Vorhaben für einen neuen Schnittstellenstandard geschaffen. Dabei gilt zunächst der Grundsatz, dass der Schnittstellenstandard aus den vorhandenen FIM-Stamminformationen generiert/abgeleitet und dann mit den betroffenen Stakeholdern abgestimmt wird. Das sind vor allem die Fachverfahrenshersteller, aber auch fachliche Vertreter aus dem Vollzug der Leistungen, also der Empfänger der Antragsdaten, und Vertreter der Herausgeber der einschlägigen Rechtsgrundlagen.


Wenn langfristig zahlreiche Liefergegenstände (Schnittstellenstandard, 1-n Online-Antragsformular(e), Papierformular(e) etc.) auf Grundlage der gleichen komplexen Fachdaten zueinander konsistent gehalten und gepflegt werden müssen, sollte es in jedem Fall ein führendes Fachdatenmodell (z.B. FIM) geben, aus dem bei Änderungen alle Liefergegenstände konsistent zueinander abgeleitet werden können. Bei einem objektorientierten Fachdatenmodell muss die Änderung an einem Fachobjekt nur an einer Stelle vorgenommen werden. Daraufhin werden konsistent alle Schnittstellen, die dieses Fachobjekt verwenden, aktualisiert. Die Liefergegenstände werden inklusive konsistenter Dokumentation generiert.


Sofern sich fachliche Cluster nicht bereits aus dem FIM-Fachdatenmodell ergeben, sollten für inhaltlich eng verwandte OZG-Leistungen Cluster gebildet werden, also fachliche „Standardfamilien“, die sich an den OZG-Themenfeldern orientieren können, wie z. B. „XBildung“ oder „XFamilie“.

Routing & Transport

Nr. Anforderung
RT1Die technischen Verbindungsdaten der zuständigen Behörden KÖNNEN bei einer geringen Anzahl bundesweit empfangender Stellen (kleiner gleich 16) direkt im Online-Dienst hinterlegt und gepflegt werden..
RT2Der Online-Dienst MUSS bei einer größeren Zahl bundesweit empfangender Stellen (>16) deren technische Adressierung mittels des Zugriffs auf das DVDV ermitteln.
RT3Bei einem Routing mithilfe des DVDV MUSS für den Online-Dienst ein DVDV-Eintragungskonzept erstellt werden.
RT4

Der Online-Dienst MUSS mindestens eine der folgenden Möglichkeiten zur verschlüsselten Übermittlung von Antragsdaten nutzen:

a) Die zu transportierenden Daten werden über einen OSCI-Sender (ggf. über eine XTA-Schnittstelle zum Sender) an die von den antragsbearbeitenden Behörden definierten OSCI-Empfänger übermittelt.

b) Die zu transportierenden Daten werden vom Online-Dienst über die FITConnect–Schnittstelle an die FIT-Connect Infrastruktur übertragen. Der Transport von dort zur antragsbearbeitenden Stelle findet in der durch diese Stelle gewählte
Art (FIT-Connect, XTA oder OSCI) statt.

Sofern es in einzelnen Fachdomänen bereits bundesweit etablierte Übertragungsstandards (z.B. ELSTER) gibt, KÖNNEN diese genutzt werden, sofern die Schutzziele Vertraulichkeit, Integrität (inkl. Authentizität) und Verfügbarkeit sichergestellt sind.

RT5Der Online-Dienst MUSS eine zertifikatsbasierte Übermittlung der Daten mit Ende-zu-Ende Verschlüsselung zwischen dem Endgerät der antragstellenden Person bzw. dem Online-Dienst bzw. dem Portal auf dem der Dienst betrieben wird und der
zuständigen Behörde ermöglichen. Die Verschlüsselung MUSS mindestens bis zu einem von der nachnutzenden Behörde zu definierenden Endpunkt reichen. Die verwendeten Zertifikate müssen der Verwaltungs-PKI entstammen.


Routing

Für die elektronische Übermittlung der Antragsdaten von der EfA-Leistung ins Backend der Verwaltung sind zum einen die für das jeweilige Verwaltungsverfahren zuständige Behörde bzw. das Fachverfahren zu identifizieren (Datenpflege im Format XZuFi) und zum anderen die technischen Adressdaten zu ermitteln (Deutsches Diensteverzeichnis). Diese beiden Aspekte (Zuständigkeitsermittlung und technische Adressierung) werden hier unter dem Begriff Antragsdaten-Routings gemeinsam betrachtet, involvieren jedoch unterschiedliche technische Komponenten. Auch beim Antragsdaten-Routing mittels FIT-Connect erfolgt eine Zuständigkeitsermittlung über das Onlinegateway des Portalverbunds und ein Abruf von technischen Adressierungsinformationen mittels des Zugriffs auf das DVDV.


Grundsätzlich bieten sich für das Antragsdaten-Routing drei Optionen, je nach den konkreten Rahmenbedingungen der EfA-Leistung. Wesentliches Kriterium ist die Anzahl der Empfänger, also der zuständigen Stellen, an die die Daten geroutet werden müssen. Darüber hinaus muss unterschieden werden, inwieweit es sich hierbei um eine homogene Behördenlandschaft handelt oder große landesspezifische Unterschiede bestehen, welcher Typ von Behörde für dieselbe Leistung zuständig ist. Eine weitere Unterscheidung ist danach vorzunehmen, ob es sich um eine stabile Zuständigkeitsverteilung handelt oder ob diese häufigen Veränderungen unterliegt. Die logische Struktur der verschiedenen Fälle ist in der unten stehenden Abbildung dargestellt.

Mit der FIT-Connect Routing-Infrastruktur steht inzwischen eine weitere Möglichkeit zur Realisierung eines Antragsdaten-Routings zur Verfügung. Die FIT-Connect Routing- Infrastruktur eignet sich sowohl für niedrige/hohe Zahlen von Empfängern, als auch für homogene/inhomogene Behördenlandschaften. Bei der Nutzung von FIT-Connect können Fachverfahren der fachlich zuständigen Behörden über ein Self-Service-Portal angelegt werden. Über die Hinterlegung von Zuständigkeitsinformationen in einem an den Portalverbund angeschlossenen Landes-Redaktionssystem (FIM Baustein Leistungen, XZuFi) können die konfigurierten Routinginformationen anschließend über den FIT-Connect Routingdienst abgefragt werden.

Relevant für die Entscheidung, ob FIT-Connect zur Entwicklung eines Onlinedienstes genutzt werden soll, ist vorrangig, ob die anzubindenden Fachbehörden einen Empfang via OSCI und/oder via FIT-Connect umsetzen können/wollen.


Abbildung 101: Entscheidungskriterien für die geeignete Infrastruktur zum Antragsdaten-Routing



Bei einer überschaubaren Anzahl an Empfängern – laut Mindestanforderungen maximal 16 – können die technischen Verbindungsdaten direkt in der EfA-Leistung gepflegt werden. Ist eine hohe Zahl von Behörden an die EfA-Leistung angebunden, an die Daten geroutet werden sollen, sind weitere Unterscheidungen notwendig. Handelt es sich bei der großen Zahl von zuständigen Behörden um einen deutschlandweit einheitlichen Behördentyp (z.B. über 5.000 Meldebehörden), muss gemäß der EfA-Mindestanforderungen als Quelle für die technische Adressierung der empfangenden Stellen das DVDV verwendet werden. Im DVDV werden Behörden durch eindeutige Schlüssel abgebildet, sodass eine EfA-Leistung dort die technische Adresse der zuständigen Behörde ermitteln kann, an welche die Antragsdaten zu übermitteln sind. Auch wenn es sich um verschiedene Behördentypen handelt, aber die Zuständigkeitszuordnung im Zeitverlauf relativ stabil ist, eignet sich das DVDV. In diesem Fall können in einer statischen Tabelle die zuständigen Behörden abgebildet und die technischen Verbindungsdaten im DVDV eingetragen werden.


In einer heterogenen Behördenlandschaft mit häufigen Änderungen der Zuständigkeiten kann es sinnvoll sein, in den einzelnen Ländern Kopfstellen einzurichten, an welche die Daten von der EfA-Leistung übermittelt und von dort an die zuständigen Behörden weiter verteilt werden. Falls in einem Land einzelne Landesbehörden für die Bearbeitung der Anträge zuständig sind, aber in anderen Ländern verschiedene regionale Niederlassungen einer Landesbehörde und in weiteren Ländern Kreise oder Kommunen, dann muss die EfA-Leistung die landesspezifischen Besonderheiten für das Antragsdaten-Routing nicht kennen. Sie muss lediglich die maximal 16 Adressen der Landeskopfstellen hinterlegen (z. B. wird für die EfA-Leistung Wohngeld geprüft, ob die Kopfstelle von IT.NRW das Antragsdaten-Routing zu den finalen Empfängerbehörden in Nordrhein-Westfalen übernimmt). Diese bis zu 16 Landeskopfstellen könnten potenziell für alle betroffenen OZG-Leistungen genutzt werden, siehe auch Kapitel 10.3.2.1 zu den Aufgaben der OZG-K.

Mit der FIT-Connect Routing-Infrastruktur steht inzwischen eine weitere Möglichkeit zur Realisierung eines Antragsdaten-Routings zur Verfügung. Die FIT-Connect Routing- Infrastruktur eignet sich sowohl für niedrige/hohe Zahlen von Empfängern, als auch für homogene/inhomogene Behördenlandschaften. Bei der Nutzung von FIT-Connect können Fachverfahren der fachlich zuständigen Behörden über ein Self-Service-Portal angelegt werden. Über die Hinterlegung von Zuständigkeitsinformationen in einem an den Portalverbund angeschlossenen Landes-Redaktionssystem (FIM Baustein Leistungen, XZuFi) können die konfigurierten Routinginformationen anschließend über den FIT-Connect Routingdienst abgefragt werden.

Grundsätzlich ist zu berücksichtigen, dass durch eine konsequente Anwendung des Once-Only-Prinzips eine engere Vernetzung zwischen Behörden eintreten wird. Dies wird nur mit einer möglichst leistungsfähigen Infrastruktur und einer einheitlichen Anbindung der Behörden zu bewältigen sein. Dies spricht für einen konsequenten Ausbau zentraler Verzeichnisdienste wie dem DVDV und der Nutzung von Plattformarchitekturen wie FIT-Connect.

Im Rahmen der technischen Umsetzung ist demzufolge zu entscheiden, ob das Antragsdaten-Routing direkt in der EfA-Leistung umgesetzt, alle beteiligten Organisationen mit ihren Diensten im DVDV eingetragen eingetragen oder eine Nutzung der FIT-Connect Routing-Infrastruktur angestrebt werden soll. Die Auslagerung der Verantwortlichkeit und Aufwände für das finale Routing an die Länder sollte nur in begründeten Ausnahmefällen erfolgen.

Um eine EfA-Leistung in das DVDV aufzunehmen, ist es notwendig, bei der Koordinierenden Stelle (KS DVDV) ein Eintragungskonzept vorzulegen. Wesentliche Inhalte des Eintragungskonzeptes sind bspw. die fachliche Beschreibung des Dienstes sowie die Benennung der Kommunikationspartner inkl. der vorgesehenen Schlüsselsystematik zur eindeutigen Identifikation der Kommunikationspartner. Weiterhin sind für alle Kommunikationspartner DOI-Zertifikate der Verwaltungs-Public-Key-Infrastruktur (PKI) zu beschaffen. Die Eintragung und Pflege aller Kommunikationsinformationen (Behörden, DVDV-Schlüssel, Rollen, Zertifikate, Dienste, technische Verbindungsdaten) erfolgt über die Pflegenden Stellen der Länder. Die Information der Betreiber der betroffenen DVDV-Server über die neu hinzukommenden Benutzer und die Information der neuen Benutzer über die Verbindungsdaten ihres DVDV-Servers sowie eines Ausweich-Servers sind weitere Schritte zur erfolgreichen Implementierung.14 Die EfA-Leistung und ggf. die Fachverfahren können eine DVDV-Bibliothek für Java und .NET verwenden, um lesende Zugriffe auf das DVDV einfach zu implementieren. Neue Verfahrensbeschreibung wird seitens Koordinierender Stelle DVDV erstellt und wird abrufbar sein unter www.dvdv.de und ein Muster-Eintragungskonzept enthalten.


Transport

Für eine adäquate Umsetzung von Datentransport und Verschlüsselung gibt es etablierte Konzepte, Standards und Produkte für unterschiedliche Anforderungen.

Beispielsweise können Middleware-Systeme (z.B. OSCI-Intermediärspostfächer oder) FIT-Connect zum Einsatz kommen, wenn kombiniert werden soll, dass das Antragsportal die Daten aktiv übermittelt („push“) und das Fachverfahren die Daten abholt („pull“). Die Ausgestaltung ist durch den LV mit den beteiligten fachverfahrensbetreibenden IT-Dienstleistern anhand der technischen Rahmenbedingungen zu klären.

Bei der Implementierung von Online-Diensten müssen derzeit heterogene IT-Infrastrukturen für die Übermittlung von Anträgenberücksichtigt werden, um die medienbruchfreie Übermittlung von Antragsdaten sicherzustellen und dabei auf Basiskomponenten unterschiedlicher Verwaltungsebenen und Behörden (bspw. auf Payment- oder Nutzerkontenkomponenten).

Die Lösung zur Übermittlung von Antragsdaten muss die Schutzziele Vertraulichkeit, Integrität (inkl. Authentizität) und Verfügbarkeit sicherstellen. Mit XTA und OSCI gibt es etablierte Technologien, die speziell für den Einsatz in der öffentlichen Verwaltung Deutschlands entwickelt wurden und auf international anerkannten IT-Standards basieren. Mit dem OSCI-Transportprotokoll lassen sich Nachrichten sicher und vertraulich übermitteln – dabei bietet der Protokollstandard eine Sicherheitsumgebung, die auf das deutsche Signaturgesetz und auf die Kommunikationsanforderungen des eGovernments optimal abgestimmt ist. Jede OSCI-Transport-Nachricht hat einen Sicherheitscontainer, der aus zwei Stufen besteht. Hierdurch lassen sich Nutzungs- und Inhaltsdaten strikt voneinander trennen, so dass die beiden Datenarten kryptographisch unterschiedlich behandelt werden können. Die Inhaltsdaten verschlüsselt der Autor der Nachricht so, dass nur der berechtigte Empfänger die Daten dechiffrieren kann. Die Nutzungsdaten werden vom Intermediär verschlüsselt, der allerdings auf die Inhaltsdaten nicht zugreifen kann. In diesem Zusammenhang spricht man oft vom „Prinzip des doppelten Umschlages“. Dank dieser Verschlüsselungen ist ein kryptographischer Angriff – ein sogenannter Man-in-the-Middle-Angriff – nahezu unmöglich.

In den Bereichen der Pass- und Ausweisbehörden, Meldebehörden, Standesämter und diverser Behörden im Kontext der Justiz und von Gewerbeanzeigen kommt in Bund, Ländern und Kommunen OSCI bereits flächendeckend für die Kommunikation zwischen Behörden zum Einsatz.

Zur Unterstützung von Verfahrensverantwortlichen bei der Umsetzung von Onlinediensten und der Anbindung von Fachverfahren steht mit FIT-Connect eine Infrastruktur zur Unterstützung der technischen Realisierung von Antragsprozessen zur Verfügung. Die entwickelte Lösung vereinfacht nicht nur den Datentransport von Onlinediensten zu Fachverfahren, sondern unterstützt auch bei Umsetzung weiterer, nicht-verfahrensspezifischer Anforderungen wie der Zuständigkeitsermittlung, der Aushandlung von Fachdatenschemata und Rückkanaloptionen und der Übermittlung von Bezahlinformationen. FIT-Connect schafft dazu eine einheitliche Schnittstelle zur Anbindung von Online-Diensten an die zuständigen Fachverfahren aller föderalen Ebenen.

Zur Etablierung eines einheitlich hohen Sicherheitsniveaus für alle angebundenen Systeme wurde eine verschlüsselte Übertragung von Antragsdaten bereits in der Konzeptionsphase des Projekts nach dem Prinzip Security by Design vorgesehen und ist ein integraler Bestandteil von FIT-Connect. Bei der Übertragung von Antragsdaten über FIT-Connect kommt neben einer obligatorischen Transportverschlüsselung immer auch zwingend eine über Zertifikate aus der Verwaltungs-PKI (V-PKI) abgesicherte Inhaltsdatenverschlüsselung zum Einsatz. Dadurch wird ein Zugriff auf Inhaltsdaten durch die FIT-Connect-Infrastruktur technisch unmöglich. Werden Inhaltsdaten dabei bereits auf dem Endgerät der Verwaltungskunden verschlüsselt, kann im Antragskontext von einer Ende-zu-Ende-Verschlüsselung gesprochen werden.

Ziel von FIT-Connect ist, die bestehende föderale IT-Landschaft effektiver zu vernetzen. FIT-Connect kombiniert dazu bestehende Produkte und Standards des IT-Planungsrates bedarfsgerecht und zielt auf die ganzheitliche Betrachtung aller Schritte der Antragstellung im Rahmen des OZG. Durch die Vereinheitlichung und Dokumentation von Prozessschritten der Antragsstellung senkt FIT-Connect die Umsetzungsaufwände für zukünftige Digitalisierungsvorhaben. Herausfordernde Problemstellungen wie z.B. das Antragsrouting werden einmal bearbeitet; entwickelte Lösungen werden allen Verfahrensverantwortlichen zur Verfügung gestellt. Weitere Informationen zu FIT-Connect finden sich auf der Webseite der FITKO unter https://www.fitko.de/projektmanagement/fit-connect. Technische Dokumentation zu FIT-Connect findet sich im Föderalen Entwicklungsportal unter https://docs.fitko.de/fit-connect/.

Zur Nutzung der vorhandenen Infrastrukturen der Länder und Kommunen ist in FIT-Connect eine OSCI/XTA-Weiterleitung für den Empfang von Nachrichten durch bestehende OSCI/XTA-basierte Strukturen vorgesehen.


Beim Einsatz von OSCI erfolgt die Anbindung der nachnutzenden Länder  im Regelfall über eine OSCI-Kopfstelle, bei der die Daten von den zuständigen Behörden abgeholt werden können. Die Bereitstellung dieses Empfängers sowie die Klärung der landesinternen Transportinfrastruktur bis zu den anzubindenden Fachverfahren ist eine zentrale Aufgabe des nachnutzenden Landes. Bei der Nutzung von FIT-Connect erfolgt die Übermittlung von Antragsdaten über den FIT-Connect Zustelldienst.


Ein bewährtes Muster für die Datenübermittlung ist das sog. 4-Corner Model mit Ende-zu-Ende-Verschlüsselung.


Abbildung 102: Schematische Transportinfrastruktur nach dem 4-Corner Model



Die EfA-Leistung wird vom Antragsportal betrieben – dem Autor der Datenübertragung (Nr. 1). Das Fachverfahren ist Leser der Datenübertragung (Nr. 4). Wenn eine Verschlüsselung der zu übermittelnden Daten durch den Autor (Nr. 1) mit den im Verschlüsselungszertifikat des Lesers (Nr. 4) hinterlegten Verschlüsselungsinformationen erfolgt, dann spricht man von einer Ende-zu-Ende-Verschlüsselung der Antragsdaten zwischen EfA-Onlinedienst und Fachverfahren.. Erfolgt die Verschlüsselung der Inhaltsdaten zwischen Sender (Nr. 2) und Empfänger (Nr. 3) (z.B. zwischen Clearing- oder Vermittlungsstellen), so spricht man demgegenüber nur von einer Transportverschlüsselung der Daten. Die übermittelten Daten sind hierbei vom Sender und Empfänger im Klartext einsehbar. Die Festlegung der Anforderungen an Datensicherheit und Datenschutz beim Transport, d.h. eine Festlegung der anzuwendenden Nutz- und Inhaltsdatenverschlüsselung erfolgt nicht in der OSCI/XTA-Spezifikation, sondern hat im Transportprofil des entsprechenden Fachdatenschemas zu erfolgen. Beim Einsatz von FIT-Connect erfolgt die Übertragung der Inhaltsdaten zwischen Autor (Nr. 1) und Leser (Nr. 4) grundsätzlich immer verschlüsselt. Zusätzlich ist mit FIT-Connect eine Verschlüsselung der Inhaltsdaten zwischen dem Endgerät der Antragsteller:in („Nr. 0“, nicht abgebildet) und dem Leser (Nr. 4) realisierbar. Nach dem 4-Corner Model werden die Daten zwischen Autor und Leser nicht direkt übermittelt, sondern über Dritte. Bei einer Vielzahl von Kommunikationsbeziehungen ist die Organisation des Nachrichtentransports eine komplexe Aufgabe. Sie beinhaltet den Umgang mit elektronischen Zertifikaten, die Identifikation und Behebung technischer Fehler, die Protokollierung etc. Die Transportaufgaben werden daher nicht bei jedem Autor und Leser separat implementiert, sondern an zentrale Komponenten für Sender (Nr. 3) und Empfänger (Nr. 4) ausgelagert.

Sowohl beim Einsatz von OSCI, als auch beim Einsatz von FIT-Connect müssen die genutzten Zertifikate einer von der öffentlichen Verwaltung kontrollierten PKI entstammen. Sender und Empfänger kennen nur die Metadaten der Datenübermittlung. Sie sichern die Zustellung ggf. inklusive einer Empfangsbestätigung. Sender und Empfänger können ein Kommunikations-Server der EfA-Leistungen bzw. des Fachverfahrens oder einer zentralen Clearing- oder Vermittlungsstelle sein.

Der Einsatz von XTA erleichtert dem Sender ggf. mehrere EfA-Leistungen anbinden zu können, ohne jeweils spezifische Lösungen implementieren zu müssen. Genauso kann der Empfänger leicht mehrere Fachverfahren anbinden. Ist das Fachverfahren ein Produkt, das für verschiedene Behörden eingesetzt wird, vereinfacht auch hier die Verwendung von XTA die Anbindung an verschiedene Empfänger.


Die für eine sichere Kommunikation notwendige Transportinfrastruktur kann so für verschiedene Anwendungsfälle für tausende Kommunikationspartner auf den Ebenen des Bundes, der Länder und vor allem der Kommunen skalierbar bereitgestellt werden.


Hauptanwendungsfall eines Dienstverzeichnisses (z. B. DVDV) ist der lesende Zugriff des Online-Dienstes, um die technischen Verbindungsdaten des Empfängers der Antragsdaten abzufragen (z. B. WSDL-Datei mit OSCI-Intermediärspostfach Adresse und Zertifikat). Die empfangende Organisation stellt unter einer spezifischen Adresse einen Dienst bereit, der Antragsdaten empfängt. Diese technischen Verbindungsdaten müssen im Diensteverzeichnis eingepflegt worden sein. Die Zuordnung zur Fachlichkeit des Antrags erfolgt über eine entsprechende Rolle der Organisation. Handelt es sich z.B. um einen Antrag zur Ausstellung eines Passes, bekommt die Organisation die Rolle „Passbehörde“. Für unterschiedliche Anträge, die an die Organisation gestellt werden können, müssen entweder jeweils eigene Dienste definiert werden oder ein Dienst wird so spezifiziert, dass er unterschiedliche Anträge entgegennehmen kann – aber stets nur für die Rolle der Organisation.


Ein zweiter Anwendungsfall für Diensteverzeichnisse kann die Überprüfung von Rollen und damit von Rechten sein. Nur die Online-Dienste registrierter Portale dürfen Anträge versenden, ggf. für eine Fachlichkeit nur sehr wenige oder sogar nur ein einziges Portal. Der empfangende Dienst kann überprüfen, ob der Online-Dienst zum Versand von Anträgen berechtigt ist. Dazu wird beim Diensteverzeichnis angefragt, ob der Besitzer des vom Absender verwendeten Zertifikats die passende Rolle hat.


Sowohl der Online-Dienst als auch der antragempfangende Dienst (das Fachverfahren der empfangenden Organisation) erhalten mit ihrer Eintragung im Diensteverzeichnis das Recht, lesend auf das Verzeichnis zuzugreifen. Sowohl für die Kommunikation mit dem Diensteverzeichnis als auch für den sicheren Versand und Empfang von Antragsdaten müssen der Anbieter des Online-Dienstes und der Anbieter des antragsempfangenden Dienstes mit jeweils einem Zertifikat und der jeweils passenden Rolle im Diensteverzeichnis registriert sein. Das DVDV als Diensteverzeichnis und die Public-Key-Infrastruktur (PKI) der Verwaltung bieten die dafür notwendige Funktionalität.

Wenn kein Diensteverzeichnis und keine PKI zum Einsatz kommen, müssen neben den Zertifikaten und den technischen Verbindungsdaten auch die Rollen der externen Kommunikationspartner bei der EfA-Leistung hinterlegt sein. Jedes Fachverfahren müsste das Zertifikat der EfA-Leistung speichern und beim Zertifikatswechsel, was etwa alle zwei Jahre vorkommt, austauschen. Bei diesem Vorgehen wird jedoch eine Gesamtübersicht über Rechte und Rollen von Behörden bei Datenübermittlungen und -abrufen schwerlich erreichbar sein.

Fazit: Unabhängig davon, ob ein Diensteverzeichnis zum Einsatz kommt, muss von den TF-FF des UL und der AL jeweils eine vertrauenswürdige Stelle damit beauftragt werden, die Daten mit den Kommunikationsparametern der Fachverfahren zu pflegen. Durch den TF-FF des UL muss zusätzlich die Eintragung des Antragsportals mit Zertifikat und korrekter Rolle erfolgen. Für das DVDV haben alle Länder sogenannte Pflegende Stellen bereits beauftragt.


Bei der Implementierung eines neuen Online-Dienstes müssen Entwickler:innen wie oben beschrieben derzeit heterogene Antragsarchitekturen berücksichtigen, um die medienbruchfreie Übermittlung von Antragsdaten sicherzustellen und dabei auf Basiskomponenten unterschiedlicher Verwaltungsebenen und Behörden zugreifen (bspw. auf Payment- oder Nutzerkontenkomponenten).



Fallbeispiel BAföG

Die Ausbildungsförderung (BAföG) ermöglicht jungen Menschen unabhängig von ihrer sozialen und wirtschaftlichen Situation eine Schul- bzw. Hochschulausbildung, die ihren Fähigkeiten und Interessen entspricht. Ausbildungsförderung kann unter bestimmten Voraussetzungen für den Lebensunterhalt und für die Ausbildung in Anspruch genommen werden. Ausbildungsförderung gibt es für Schüler:innen, Studierende, Praktikant:innen sowie für die Fortbildung oder den Besuch einer im Ausland gelegenen Ausbildungsstätte. Für die Leistung müssen nach dem Erstantrag je nach Bedarf regelmäßig Folgeanträge gestellt werden. Für den Antrag müssen in hohem Umfang Angaben zur Lebenssituation (u.a. Wohn-, Einkommens- und Vermögenssituation) eingereicht werden, in vielen Fällen zusätzlich zu den Antragstellenden auch von deren Eltern. Aktuell gibt es ca. 675.000 BAföG-Empfänger:innen in Deutschland.


Aufgrund einer gesetzlichen Pflicht im BAföG-Gesetz verfügten alle Länder bereits seit dem Jahr 2016 über ein „Online-Formular“. Allerdings wurden diese in verschwindend geringem Umfang genutzt (vgl. BT-Drs. 19/14242), sodass aus Sicht des federführenden Landes sowie Bundesressort nichtsdestotrotz im Digitalisierungslabor eine nutzerfreundliche Lösung konzipiert werden sollte.


Bereits über diese Auswahlentscheidung sowie fortlaufend über den Projektfortschritt wurde die zuständige Bund-Länder-Arbeitsgruppe der Kultusministerkonferenz informiert. Diese wurde insbesondere mit Blick auf die Fachmodellierung der Antragsstrecke und die Gestaltung der Schnitt-stelle zur Anbindung der Fachverfahren eingebunden. Bereits frühzeitig wurden hierfür alle drei Hersteller der bundesweit von den ca. 90 BAföG-Ämtern eingesetzten Fachverfahren an der Spezifikation beteiligt.


Die Finanzierungsfragen wurden dadurch erleichtert, dass seitens des Bundes die Beauftragung für einen IT-Dienstleister übernommen wurde, der einen EfA-fähigen Online-Dienst entwickelte, welcher später von den öffentlichen IT-Dienstleister des federführenden Landes betrieben werden sollte (Weg 2).


Ebenfalls im Rahmen der ebenenübergreifenden Zusammenarbeit wurde in der Bund-Länder-AG frühzeitig die Aushandlung einer Verwaltungsvereinbarung als rechtliche Grundlage für den gemeinsamen Betrieb des Online-Dienstes begonnen. Diese war bereits zum Go Live von BAföG digital in fünf Ländern Ende Oktober 2020 von mehr als den Pilotländern unterzeichnet. Die Verwaltungsvereinbarung regelt zudem die langfristige gemeinsame Kostentragung aller Länder und schafft die Governance für die Pflege und Weiterentwicklung des Dienstes.



Abbildung 103: Erfolgsfaktoren Umsetzung BAföG


Ende Oktober 2020 ging https://www.bafoeg-digital.de/ unmittelbar für fünf Länder live (ST, BE, HE, NW, RP). Diese Länder decken ungefähr 50% der Studierenden in Deutschland ab. Nach weniger als fünf Monaten wurden ca. 18.000 BAföG-Anträge mit BAföG digital fertiggestellt und eingereicht. Zusätzlich wurden über 5.000 sog. Elternerklärungen zu den Anträgen eingereicht. Damit übersteigen die Nutzungszahlen von BAföG digital die Werte der bisherigen Online-Formulare früherer Jahre um ein Vielfaches.


Stand: 10.11.2022

  • No labels