how_to_vote Funktionsbaustein: Initiierung einer Verwaltungsleistungfeedback
| Eigenschaft | Wert |
|---|---|
| Kennung | DArch-FBS-IVL |
| Hauptfähigkeit | E-Government |
| Geschäftsfähigkeit | E-Gov-Basisdienste |
| Version | 0.3 (13.05.2026) |
| GovStack-Bezug | Registration Building Block |
summarize 1 Management Summaryfeedback
Der Baustein Initiierung einer Verwaltungsleistung deckt die vollständige digitale Antragsstrecke für einfache bis mittelkomplexe Verwaltungsverfahren. Er stellt Oberflächen, Formulare und Schnittstellen zu IT-Verfahren auf Low-Code-/No-Code-Plattformen bereit und setzt Verwaltungsleistungen auf ressourcenschonender Entwicklungsbasis um. Neben der klassischen Bürger-Antragstellung ermöglicht der Baustein auch die interaktive Einbindung externer Partner (Gutachter, Prüfer, etc.) und die behördeninterne (teil-)automatisierte Initiierung von Vorgängen – etwa nach dem Eintreten definierten Ereignisse wie der Geburt eines Kindes oder einer Änderung im Melderegister.
description 2 Beschreibungfeedback
2.1 Kontextdiagrammfeedback
- Der Baustein Initiierung einer Verwaltungsleistung verarbeitet Antragsdaten, die von Nutzenden über den Baustein Zentrale Nutzenden-Frontend eingereicht werden.
- Der Baustein Initiierung einer Verwaltungsleistung stellt eigene Antragsformulare für die Entgegennahme von Antragsdaten bereit und stellt die nutzendenzentrierte Kommunikation nach dem Reifegradmodell 2.0 sicher
- Authentifizierte Nutzende (über den Baustein Authentifizierung) – BürgerInnen, Unternehmen oder behördeninterne Sachbearbeitende – füllen Formulare aus und reichen Nachweise ein
- Der Baustein Nachweisdatenabruf ruft auf Wunsch und nach erfolgter Freigabe durch den Nutzenden Nachweise direkt aus Registern ab
- Der Baustein KI-Querschnittsdienste liefern kontextbezogene Ausfüllhilfen
- Abgeschlossene Anträge werden über gesicherte Protokolle an das Fachverfahren übergeben
- Der Baustein Postfach und Interaktion kann für die Eingangsbestätigungen, Statusmeldungen und Bescheidzustellung verwendet werden
- Ein-/Auszahlungsprozesse laufen über den Baustein Ein-und Auszahlung
menu_book 3 Terminologiefeedback
Die folgende Tabelle definiert die wesentlichen Fachbegriffe im Kontext des Bausteins Initiierung einer Verwaltungsleistung.
| Begriff | Definition |
|---|---|
| Antragsstrecke | Die technische Abfolge von Schritten, die ein Nutzender von der Anmeldung bis zur Einreichung durchläuft – von der Authentifizierung über Formularanzeige, Validierung und Nachweisabruf bis zur gesicherten Datenübergabe an das Fachverfahren |
| Low-Code-Plattform | Entwicklungsumgebung, die Anwendungen primär durch grafische Modellierung (Formulare, Prozesse, Konnektoren) erstellt. Ergänzender, klassischer Programmiercode ist grundsätzlich zulässig, aber soll in der Regel durch die grafische Modellierung ersetzt werden |
| Once-Only-Prinzip | Grundsatz, nach dem Nutzende bereits in Registern vorliegende Nachweise nicht erneut einreichen müssen. Technisch umgesetzt über NOOTS |
| NOOTS | National Once-Only Technical System. Zentrales System der Registermodernisierung in Deutschland für den automatisierten Nachweisabruf zwischen Behörden auf Basis des eIDAS-2.0-Rahmenwerks |
| E2E-Digitalisierung | Medienbruchfreie Abwicklung eines Verwaltungsverfahrens von der Antragstellung bis zur Bescheidzustellung auf einer gemeinsamen technischen Plattform ohne manuelle Systemwechsel |
settings 4 Kernfunktionalitätenfeedback
Der Baustein Initiierung einer Verwaltungsleistung umfasst acht Kernfunktionalitäten:
4.1 App-Builderfeedback
Grafisches Werkzeug zur Erstellung von Formularen, Seitenflüssen und Eingabemasken. Unterstützt alle für Verwaltungsverfahren üblichen Feldtypen (Text, Zahl, Datum, Auswahlliste, Datei-Upload (BLOB), IBAN, Signatur). Formulare werden WCAG-2.1-konform und responsiv gerendert. Komponenten lassen sich als wiederverwendbare Bausteine ablegen.
4.2 Logikmodellierungfeedback
Modellierung von Prozessen, Prozessregeln, Verzweigungen und Validierungslogiken über BPMN 2.0 oder dem jeweiligen, plattformeigenen Regeleditor. Entscheidungsbäume, Pflichtfeldprüfungen und dynamische Formularsteuerung werden weitgehend ohne klassischen Programmiercode abgebildet. Komplexe Regelwerke lassen sich versioniert und nachnutzbar in einer Regelbibliothek als nachnutzbare Komponente hinterlegen.
4.3 Datenmodellierungfeedback
Definition der Fachobjekte und ihrer Attribute (Antragsteller, Antragsdaten, Anlagen, Nachweise, Zahlungsreferenz, Widerspruch, etc.). Schemata werden versioniert und im Repository gepflegt.
4.4 Konnektoren und Integrationfeedback
Vorkonfigurierte Adapter für alle Pflichtschnittstellen: Nachweisdatenabruf, Authentifizierung, Zentrales Nutzenden-Frontend, Vorgangs- und Sachbearbeitung, Datenaustausch, Postfach und Interaktion, Ein- und Auszahlung, KI-Querschnittsthemen. Neue Konnektoren werden über eine REST-Schnittstelle oder andere geeignete Methoden weitgehend ohne Eingriff in den Plattformkern ergänzt.
4.5 App-Lifecycle-Managementfeedback
Vollständige Verwaltung von Anwendungsartefakten über den gesamten Lebenszyklus: Entwicklung, automatisierter Test, Freigabe und (teil-)automatisierte Deploymentpipeline (CI/CD) bis in die Produktion (DevSecOps). Versionsverwaltung verhindert unkontrollierte Änderungen.
4.6 Vorgangsmanagementfeedback
Verwaltung laufender Vorgänge auf Antragstellerseite: Speichern und Wiederaufnehmen von Entwürfen, Statusverfolgung, Nachreichung von Dokumenten und Anzeige von Behördenrückfragen. Schnittstelle zum Postfach-Dienst für automatisierte Statusbenachrichtigungen an Nutzende.
4.7 Sicherheit Initiierung VLfeedback
Umsetzung der Sicherheitsvorgaben auf Ebene der Antragsstrecke: BSI-Grundschutz 200-1 bis 200-3, DSGVO, BDSG, BSI Grundschuzkompendium. Umfasst Rollenkonzept (RBAC), Transportverschlüsselung, Session-Management, Audit-Logging etc. Die Trennung in Zonen (Internetzone (DMZ) für Antragstellung, Intranetzone für Vorgangsbearbeitung) ist vorgesehen.
4.8 Protokolle Initiierung VLfeedback
Vollständige, revisionssichere Protokollierung aller Antragsaktionen: Erstellung, Änderung, Einreichung, Statuswechsel, Nachreichungen und Löschungen. Protokolldaten stehen für Audit-Anfragen sowie Datenschutz-Folgenabschätzungen bereit.
shield 5 Querschnittsanforderungenfeedback
Dieser Abschnitt beschreibt übergreifende Anforderungen, die für den Baustein gelten.
Klassifikation: • Verbindlichkeit: Erforderlich, Empfohlen, Entwurf, Veraltet. • Erweiterbarkeit und Austauschbarkeit: Unveränderlich, Erweiterbar, Austauschbar, nicht anwendbar.
| ID | Anforderungen | Klassifikation |
|---|---|---|
| QA-IVL-01 | Alle Datenübertragungen sind verschlüsselt. | Erforderlich; Unveränderlich |
| QA-IVL-02 | Nutzerauthentifizierung läuft ausschließlich über föderierte Identitätsdienste (BundID, ELSTER-OK, perspektivisch EUDI-Wallet). Eine eigene Nutzerverwaltung mit Passwortdatenbank ist nicht zulässig. | Erforderlich; Unveränderlich |
| QA-IVL-03 | Formulare und Oberflächen erfüllen WCAG 2.1 sowie BITV 2.0 Anforderungen. Die Konformität ist vor Produktivstellung durch einen Accessibility-Test nachzuweisen. | Erforderlich; Erweiterbar |
| QA-IVL-04 | Der Baustein ist mandantenfähig: Verfahren verschiedener Behörden laufen isoliert auf derselben Instanz. Datenzugriff über Mandantengrenzen hinweg ist technisch ausgeschlossen. | Erforderlich; Unveränderlich |
| QA-IVL-05 | Alle Protokolldaten werden revisionssicher gespeichert und mindestens 10 Jahre aufbewahrt. Protokolldaten dürfen nachträglich nicht verändert oder gelöscht werden. | Erforderlich; Unveränderlich |
| QA-IVL-06 | Der Baustein nutzt ausschließlich Low-Code-Plattformen aus dem im D-Stack definierten und genehmigten Produktportfolio. Abweichungen erfordern eine schriftliche Ausnahmegenehmigung. | Erforderlich; Austauschbar |
| QA-IVL-07 | Der Baustein unterstützt Mehrsprachigkeit. Mindestens Deutsch und Englisch müssen ohne Neuentwicklung konfigurierbar sein. Weitere Sprachen werden über Übersetzungsdateien ergänzt. | Erforderlich; Erweiterbar |
| QA-IVL-08 | Antragsdaten werden nach Übergabe an das Fachverfahren nicht dauerhaft im Baustein gespeichert. Entwürfe werden nach 90 Tagen Inaktivität automatisch gelöscht; der Nutzende wird 7 Tage vorher benachrichtigt. | Erforderlich; Erweiterbar |
checklist 6 Funktionale Anforderungenfeedback
Die funktionalen Anforderungen beschreiben die konkreten Fähigkeiten, die der Baustein bereitstellen muss.
Klassifikation: a) Verbindlichkeit: Erforderlich, Empfohlen, Entwurf, Veraltet. b) Erweiterbarkeit und Austauschbarkeit: Unveränderlich, Erweiterbar, Austauschbar, nicht anwendbar.
6.1 Anforderungen App-Builderfeedback
| ID | Anforderungen | Klassifikation |
|---|---|---|
| FA-APP-01 | Formulare werden responsiv gerendert. Die Darstellung auf Mobilgeräten wird ohne separate Mobile-Variante des Formulars erzielt. | Erforderlich / Unveränderlich |
| FA-APP-02 | Formularinhalte sind in mind. Deutsch und Englisch anzeigbar. Die Sprachauswahl erfolgt durch den Nutzenden vor oder während des Antragsprozesses. | Erforderlich / Erweiterbar |
| FA-APP-03 | Teilausgefüllte Anträge können gespeichert und zu einem späteren Zeitpunkt fortgesetzt werden (Draft-Funktion). Der gespeicherte Stand liegt serverseitig verschlüsselt vor; eine Speicherung ausschließlich im Browser-Cache ist nicht zulässig. | Erforderlich / Unveränderlich |
6.2 Anforderungen Logikmodellierungfeedback
| ID | Anforderungen | Klassifikation |
|---|---|---|
| FA-LOG-01 | Prozessregeln und Verzweigungen werden in BPMN 2.0 oder dem plattformeigenen Regeleditor modelliert. Der Export als BPMN-Datei ist möglich. | Erforderlich / Austauschbar |
| FA-LOG-02 | Dynamische Formularsteuerung (Ein-/Ausblenden von Feldern und Abschnitten) wird über Bedingungsregeln gesteuert, die im Regeleditor ohne Programmierung konfiguriert werden. | Erforderlich / Unveränderlich |
| FA-LOG-03 | Validierungsregeln (Pflichtfelder, Formatprüfungen, Plausibilitätschecks) werden sowohl clientseitig als auch serverseitig ausgeführt. Eine ausschließlich clientseitige Validierung ist nicht zulässig. | Erforderlich / Unveränderlich |
| FA-LOG-04 | Regelwerke werden versioniert gespeichert. Frühere Versionen sind jederzeit abrufbar; eine Änderungshistorie zeigt Autor, Datum und geänderte Regel. | Erforderlich / Erweiterbar |
6.3 Anforderungen Datenmodellierungfeedback
| ID | Anforderungen | Klassifikation |
|---|---|---|
| FA-DAT-01 | Antragsdaten werden mit einem Zeitstempel und der Verfahrenskennung (LeiKa-Nummer) versehen und sind über die eindeutige Antrags-ID jederzeit abrufbar. | Erforderlich / Austauschbar |
| FA-DAT-02 | Über NOOTS abgerufene Nachweise werden im Antragsdatensatz referenziert (Nachweis-ID, Quellenregister, Abrufzeitpunkt, Einwilligungsnachweis). Die Nachweisdaten selbst werden nach Übergabe ans Fachverfahren nicht dauerhaft gespeichert. | Erforderlich / Unveränderlich |
6.4 Anforderungen Konnektoren und Integrationfeedback
| ID | Anforderungen | Klassifikation |
|---|---|---|
| FA-KON-01 | Der Baustein stellt einen NOOTS-Konnektor bereit. Nach expliziter Einwilligung des Nutzenden ruft er Nachweise (Geburtsurkunde, Einkommensnachweis, Gewerbeanmeldung u. a.) automatisiert aus dem zuständigen Register ab und befüllt die Formularfelder. | Erforderlich / Austauschbar |
| FA-KON-02 | Die Anbindung an den Baustein Ein- und Auszahlung erfolgt über REST-API. Zahlungsstatus, Transaktions-ID und Gebührenbetrag werden im Antragsdatensatz gespeichert. Das Verfahren kann ohne Zahlung nicht eingereicht werden, sofern Gebührenpflicht konfiguriert ist. | Erforderlich / Austauschbar |
| FA-KON-03 | Antragsdaten werden über FITConnect an das Fachverfahren übermittelt. | Erforderlich / Austauschbar |
| FA-KON-04 | Authentifizierung läuft BundID oder ELSTER-OK. Die EUDI-Wallet-Integration ist vorzubereiten und wird bei Verfügbarkeit der Infrastruktur aktiviert. | Erforderlich / Erweiterbar |
| FA-KON-05 | Statusmitteilungen (Eingangsbestätigung, Rückfragen, Bescheid) werden über den Baustein Postfach und Interaktion zugestellt. Die Zustellbestätigung wird im Antragsdatensatz protokolliert. | Erforderlich / Erweiterbar |
6.5 Anforderungen Sicherheit Initiierung VLfeedback
| ID | Anforderungen | Klassifikation |
|---|---|---|
| FA-SEC-01 | TODO | TODO |
6.6 Anforderungen Protokolle Initiierung VLfeedback
| ID | Anforderungen | Klassifikation |
|---|---|---|
| FA-PRO-01 | Jede Antragsoperation (Erstellung, Änderung, Einreichung, Statuswechsel, Löschangang) erzeugt einen signierten Protokolleintrag mit Zeitstempel (UTC), Nutzenden-Pseudonym, Verfahrenskennung und Änderungsdetail. | Erforderlich / Unveränderlich |
| FA-PRO-01 | Protokolldaten werden in einem vom Anwendungsbetrieb getrennten, schreibgeschützten Speicher abgelegt. Schreibzugriff auf Protokolldaten ist ausschließlich dem Protokoll-Service erlaubt. | Erforderlich / Unveränderlich |
| FA-PRO-01 | Protokolle sind über eine gesicherte Admin-Schnittstelle nach Verfahrenskennung, Zeitraum und Nutzenden-Pseudonym abfragbar. Der Zugriff ist auf autorisierte Administratoren beschränkt und wird selbst protokolliert. | Erforderlich / Unveränderlich |
database 7 Datenstrukturenfeedback
Die Datenstrukturen beschreiben die relevanten Datenformate und -modelle für den Baustein.
| ID | Datenstruktur | Standard | Beschreibung |
|---|
api 8 Service-Schnittstellenfeedback
Dieser Abschnitt enthält eine Referenz für die APIs, die von diesem Baustein implementiert werden sollten. Die hier definierten APIs bilden die Grundlage für die Interaktion des Bausteins mit anderen Bausteinen. Der Baustein kann zusätzliche APIs implementieren, die aufgeführten APIs definieren jedoch einen minimalen Funktionsumfang, der in jeder Implementierung dieses Bausteins enthalten sein sollte.
| Schnittstelle | Richtung | Protokoll | Beschreibung |
|---|
account_tree 9 Interne Workflowsfeedback
library_books 10 Weiterführende Informationen und Quellenfeedback
Links zu Ressourcen wie Anwendungsfallbeschreibungen, Architekturanforderungen sowie zugehörige Standards und Normen.
- GovStack Building-Block-Spezifikationen
- FITConnect Entwicklerdokumentation
- OZG 2.0 – Onlinezugangsgesetz
- WCAG 2.1 Konformitätsleitfaden / BITV 2.0
- [Referenzarchitektur Low Code Fabrik Bund (Langfassung), Ver. 1.0, Stand 14.01.2026, BMDS AG DS I 1]
- [Reifegradmodell 2.0, BMDS (https://www.digitale-verwaltung.de/Webs/DV/DE/onlinezugangsgesetz/ozg-grundlagen/info-reifegradmodell/info-reifegradmodell-node.html)]
- [BSI Grundschutzkompendium (https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/IT-Grundschutz-Kompendium/it-grundschutz-kompendium_node.html)]