Register, Once-only und Zweckbindung

Once-only soll Menschen und Unternehmen davon entlasten, dieselbe Angabe wiederholt einzureichen. Es ist kein pauschaler Zugriffstitel für jede Behörde. Ein Registerabruf bleibt eine verantwortete Entscheidung über Zuständigkeit, Zweck, Attribute und Zeitpunkt.

Vorher: Governance im Public Sector. Weiter: E-Akte und Analytics-Lifecycle.

Ansatz

Jeder produktive Registerabruf erhält einen versionierten Retrieval Contract:

1. abrufende und registerführende Stelle;
2. gesetzlich und fachlich bestätigter Zweck;
3. benötigte Attribute statt vollständigem Registerprofil;
4. Identifier, Gültigkeitszeitpunkt und Qualitätsstatus;
5. Protokollierung, Korrektur- und Widerspruchspfad;
6. Regeln für lokale Kopie, Cache und Löschung.

Legal/Privacy und die zuständige Fachseite bestätigen die Authority. Integrationsteams setzen die Entscheidung um.

Operating Workflow

1. Bedarf begründen

Die abrufende Stelle beschreibt die konkrete Verwaltungsentscheidung. „Prozessoptimierung“ genügt nicht als Zweck.

2. Attribute minimieren

Für jedes Feld wird geprüft, ob Identifier oder Ja/Nein-Nachweis statt eines vollständigen Datensatzes reichen.

3. Quelle und Zeitpunkt binden

Antworten tragen Register, Version, Abrufzeitpunkt und fachliche Gültigkeit. So bleibt nachvollziehbar, welcher Zustand verwendet wurde.

4. Zugriff erzwingen

Service-Identität, Purpose Code, Scope und Empfänger werden technisch gebunden. Ein Deny-Test belegt, dass ein anderer Zweck nicht durchkommt.

5. Fehler zurückführen

Lokale Korrekturen dürfen das Register nicht unsichtbar überschreiben. Ein definierter Kanal verbindet Betroffene, abrufende Stelle und Registerführung.

6. Sekundärnutzung neu entscheiden

Analytics, Statistik oder AI sind nicht automatisch vom operativen Abruf umfasst. Sie erhalten eine eigene Zweck- und Lifecycle-Entscheidung.

Minimaler Evidence Pack

• bestätigter Retrieval Vereinbarung und Authority;
• technische Richtlinie-Version und Service-Identität;
• positiver und negativer Abruf;
• Protokoll mit Zweck, Attributen und Zeitpunkt;
• Korrektur- und Löschtest;
• Liste offener Ausnahmen mit Ablaufdatum.

Anti-Patterns

• Das gesamte Registerprofil wird „für später“ gespeichert.
• Purpose Codes sind frei wählbarer Request-Text.
• Lokale Caches besitzen weder Version noch Löschregel.
• Fachverfahrensfehler werden als Registerfehler behandelt.
• Statistik übernimmt operative Kopien ohne neue Entscheidung.

Erster Umsetzungsschnitt

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Public Sector Landscape
• Lernpfad — Public Sector Landscape

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Einen volumenstarken Abruf auswählen.
2. Attribute und tatsächliche Nutzung vergleichen.
3. Einen unnötigen Wert entfernen.
4. Purpose Code und Service-Identität technisch binden.
5. Deny- und Korrekturfall testen.
6. Cache-Frist und Sekundärnutzung entscheiden.