Epic: Automatisierte Aktualisierung von unterstützten XÖV-Fachdatenschemata im Zustellpunkt [RICE 35,9]
Pitch
Outcome:
Auf welches strategische Ziel zahlt das Feature ein? Was ändert sich, wenn das Feature verfügbar ist?
- Kundenbindung durch erleichterte Konfiguration
Zielgruppe:
Wer profitiert von diesem Feature?
- Verwalter von Zustellpunkten.
Opportunity:
Welches Problem lösen wir bei unserer Zielgruppe?
- Bei XÖV-Standars gibt es jährlich eine neue Version. Bei XPersonenstand wird z.B. an jedem 1. November eine neue Version gültig und Vorgängerversion wird eine Woche später ungültig.
- Verwalter von Zustellpunkten, bei denen sich ein Fachdatenschema auf einen solchen XÖV-Standard bezieht, müssen jedesmal das im Zustellpunkt angegebenen Fachdatenschema aktualisieren, was einen großen Aufwand darstellt.
- Die ÜBergangszeit, in der zwei Versionen parallel gültig sind, ist sehr kurz.
- Die betreffenden Fachverfahrenshersteller sind auf diesen Release-Zyklus eingestellt.
- Es ist daher davon auszugehen, dass zu dem Zeitpunkt, zu dem eine neue Version gültig wird, alle relevanten Fachverfahren aller Behörden die neue Version unterstützen.
- Dadurch erscheint die manuelle Aktualisierung des Fachdatenschemas im Zustellpunkt einen überflüssigen Aufwand darzustellen.
- Es wäre zwar sinnvoller, wenn die Fachverfahrenshersteller in ihrem Fachverfahren die Destination-API implementieren würden und die Verwaltung der Destination samt der Aktualisierung des Fachdatenschemas aus dem Fachverfahren heraus vornehmen würden, bisher gibt es aber kaum Hersteller, die dazu bereit sind.
Kurzbeschreibung:
- Im SSP kann bei "Unterstützte Schemata der Verwaltungsleistung" die Einstellung "XÖV-Standard - Automatisch die gültige(n) Version(en) unterstützen." aktiviert werden. Dazu muss ein XÖV-Standard (URI muss mit
urn:xoev-de:beginnen) und die gewünschte Nachricht aus dem Standard gewählt werden. Bsp.urn:xoev-de:kosit:standard:xinneres.xpersonenstandundportal2StA.Sterbefall.084010. - Ein Service (Cron Job?) prüft regelmäßig bei allen Schemata aller Zustellpunkte, bei denen diese Einstellung aktiviert ist, ob es im XRepository (über dessen API) eine neue gültige Version gibt bzw. eine bisher eingestellte ungültig geworden ist. Dazu werden die Attribute "gültig ab"... "bis" ausgewertet.
- Wurde eine neu gültige Version gefunden wird geprüft, ob in der neuen Version weiterhin die eingestellte Nachricht enthalten ist. Wenn ja, wird ein entsprechendes neues Fachdatenschema hinzugefügt.
- Wurde festgestellt, dass ein bestehendes Fachdatenschema nicht mehr gültig ist, wird es entfernt.
- An die E-Mail-Adresse des technischen Ansprechpartners des Zustellpunktes wird eine Nachricht geschickt, immer wenn
- Ein neues Schema hinzugefügt wurde.
- Ein bestehendes Schema entfernt wurde.
- Existiert nach dem Entfernen eines Schemas zu dem eingestellten Standard und der eingestellten Nachricht kein gültiges Schema mehr, wird in der Benachrichtigung mit einer Warnung darauf hingewiesen.
- Eine Warnung wird auch an die technischen Ansprechpartner geschickt, die das Feature nicht aktiviert haben, wenn ein nicht mehr gültiges XÖV-Fachdatenschema eingetragen ist.
- Der Service cached XÖV-Versionen und deren Gültigkeitszeitraum, um vorbereitet zu sein, falls das XRepository zum Umstellungszeitpunkt nicht erreichbar ist.
Was ist sonst noch wichtig zu wissen?
Bsp. wie Fachdatenschema-URIs bei XÖV-Standards bisher angegeben werden:
urn:xoev-de:bmk:standard:xbau_2.2#baugenehmigung.antrag.0200urn:xoev-de:kosit:standard:xinneres.xpersonenstand_25.11#portal2StA.Sterbefall.084010
Mockup
Entscheidungen:
Gibt es Entscheidungen, die jetzt schon getroffen werden sollten? Sind Beschaffungen notwendig?
-
Schritt 1: Zunächst soll ein Mockup erstellt werden, um über das Anbindungsmanagement die Akzeptanz eines solchen Features zu prüfen.
-
Schritt 2: Unabhängig von der automatischen Aktualisierung wird bei abgelaufenen XÖV-Fachdatenschemata eine Erinnerungsmail gesendet.
-
Anstatt für einen Verwaltungsleistung die automatische Pflege aller gültigen Fachdatenschemata (spezifiziert durch ID des XÖV-Standards und der ID der Nachricht aus dem Standard) anzubieten, könnte auch nur die Aktualisierung eines spezifisch (wie bisher) angegebenen XÖV-Fachdatenschemas auf die höchste gültige Version angeboten werden. Wäre das einfacher zu implementieren bzw. in der Destination-API kompatibler?
(Externe) Deadline:
Gibt es externe Deadlines die berücksichtigt werden müssen?
- NRW hat konkrete Anforderungen gestellt, deren Umsetzung perspektivisch in laufende Projekte eingebunden werden muss.
- Harmonisierung mit Zustelldienst-Schnittstellen erfordert zeitnahe Abstimmungen (2025).
Prioritätsbewertung:
Wie gewichten wir die RICE Faktoren auf einer Skala von 1 bis 10?
Reach: 6,4
Impact: 4,9
Effort: 5,5
Confidence: 6,3
RICE-Gesamtscore: 35,9
Vorbereitung Epic Refinement
- Wer kümmert sich darum, dass ein Epic "refinement ready" gemacht wird?
→ PO SSP (Laura Elges) in enger Abstimmung mit PO Routing. - Welche Teams werden perspektivisch am Feature arbeiten? Welche Devs aus den Teams sollten jetzt schon eingebunden werden?
→ Teams: SSP, INF, Routingdienst.
→ Devs: Keycloak-Admin, Schnittstellenentwickler, Dokumentationsteam. - Bei welchem Epic Refinement kann dieses Feature voraussichtlich besprochen werden?
→ Q4/2025 im Rahmen des SSP-Refinement.
Persona
Name und Rolle: Martina, IT-Leiterin in einer Kommune.
User Story:
Als IT-Leiterin möchte ich sicherstellen, dass meine Fachverfahren automatisch die aktuellen Metadatenschemata nutzen, damit ich weniger manuellen Abstimmungsaufwand habe und fehlerfreie Datenverarbeitung gewährleisten kann.
Jobs
- Verwaltung von Verträgen und Anbindungen.
- Koordination zwischen Fachverfahren und FIT-Connect.
Pains
- Hoher Aufwand durch manuelle Pflege.
- Unklare Rollenverteilungen und Zuständigkeiten.
Gains
- Zeitersparnis durch Automatisierung.
- Transparenz über Datenstände und Versionen.
- Sicherheit durch zertifikatsbasierte Zugänge.
Epic Ausarbeitung
Warum
Um die Nutzung von FIT-Connect langfristig effizient und zukunftssicher zu gestalten, ist eine Erweiterung über Transport und Routing hinaus notwendig. Rollenmodelle, Herstellerprofile und API-Erweiterungen schaffen die Grundlage für echte Ende-zu-Ende-Digitalisierung.
Ziel
FIT-Connect unterstützt Verwaltungen und Hersteller nicht nur bei der Datenübertragung, sondern auch bei der strukturierten Verwaltung und Zusammenarbeit.
Links, Hinweise, Bemerkungen
- NRW-Anforderung zu Herstellerintegration
Stories
-
Herstellerprofile im SSP anlegen und pflegen. -
Keycloak-Gruppe für Elster-MUK-Zertifikate einrichten. -
Automatisierte Herstellersteuerung implementieren. -
Absenderbeschränkung erweitern. -
Destination API Patch spezifizieren und testen. -
Quality Gate: Validierung der Herstellerrollen und API-Erweiterung.
Akzeptanzkriterien
-
Hersteller können Metadatenschema und Fachdatenschema selbst verwalten. -
Rollen & Rechte werden über Keycloak gesteuert. -
Automatisierte Informationsausgabe (Ping) ist möglich. -
Destination API Patch ist erfolgreich getestet. -
Definition of Done wurde überprüft. -
Anpassung der Betriebs- und öffentlichendokumentation
Mögliche Folgeaktivitäten
- Erweiterung in SDKs (Java, .NET).
Offene Fragen
- Welche Governance-Regelungen für Herstellerprofile sind notwendig?
- Wie eng soll die Kopplung mit Zustelldiensten technisch erfolgen?
- Wer trägt die Verantwortung für Datenvalidierung im automatisierten Prozess?

