TH: Adressierung von Verfahrensbeteiligten im Vorgangsraum

Besprechung zum Thema “Rollenspezifische Adressierung von Nachrichten” / 11.09.2026

TH spricht hier für den Steuerungkreis EfA - der die Einführung von generischen Nachrichten zur Adressierung von Verfahrensbeteiligten für notwendig erachtet - mit einigen unterstützenden Funktionalitäten, ohne die das nicht funktionieren kann

Anwendungsfälle:

Die BAB sendet an bestimmte Akteure im Vorgangsraum - dort soll vollständig das Rollenmodell XBau abgebildet sein, das involviert auch:

• zuweisen, ändern im Vorgangsraum
• einladen in den Vorgangsraum
• individuell und bilateral kommunizierbar

 Bescheide im Rahmen der BAB

• zustellen an bestimmte Akteure
• nicht abdeckbar über Vertretungsvollmachten
• an Bauleiter, Fachplaner, usw.
• Baulastbegünstiger, -geber usw.
• weitere

Ideen zur Umsetzung: ggf. im Nachrichtenkopf / Rollen-ID in die Adressierung mit aufnehmen / Mechanismen schärfen - Mitteilung an die Fachsoftware, welche Akteure erreichbar sind

 Fragen, die dadurch aufgeworfen werden (cit)

• Vorgangsraum initial Konstellation, wie fortzuschreiben
• für welche Nachrichten sinnvoll?
• wie ist mit der Nachricht umzugehen - was ist wenn die Rolle ausgeladen wird, ist dann die Nachricht an diese Person nicht mehr zu sehen im Vorgangsraum?
• betrifft nur 1142? oder auch prozessnachrichten.zustellungSchreiben.1141
• Fehlersituationen mit Rückweisungen - müssen unterschieden und beschrieben werden
• einige Punkte sind vom Standard festzulegen, andere Punkte vom IT-Verfahren (Implementierungskontext)

 Erwartungen aus Sicht Umsetzung in EfA (BrainSCC)

• dass der Standard diese Mechnismen hinreichend detailliert festlegt, so dass implementierbar (keine Unklarheiten)
• hins. Nachricht 1142 - hier sehen wir keine Komplikationen
• hins. Bescheidnachrichten wie 0205 - Fragen: soll dann ggf. anderen Rollen verborgen werden? -
  • Hinweis: steht das im Konflik mit dem fachlichen Statuswechsel? das wäre zu vermeiden - der Statuswechsel wird benötigt den gesamten Vorgangsraum betreffend, das Dokument Bescheid aber ggf. nur für den Bauherrn einsehbar (plus ggf. für den Vertretungsberechtigten; gerade in Unternehmen in der Bauherren-Rolle gibt es extensive Vertretungsregelungen)
• hins. Nachricht an den Gebührenempfänger - ist zu prüfen

 Diskussion:

• reden wir über die Adressierung von Nachrichten in die Inbox (Nutzeraccount), oder eher " für wen ist welche Nachricht einsehbar, die im Vorgangsraum vorhanden ist"
• über letzteres, in EfA werden Nachrichten in die Inbox (Nutzeraccount) nur als Notifikation eingesetzt

 Umsetzung könnte sein aus Sicht des Antragstellers:

1. Einige fachliche und generische Nachrichten an den Projektraum richten mit UUID von bestimmten Akteuren plus Angabe der Rolle - für die Zustellung dedizierter Dokumente oder Informationen
2. Rücknachricht an die BAB, welche Akteure gibt es jetzt im Projektraum
3. Nachricht an den Projektraum: löschen von Verfahrensbeteiligten, neue anfordern, weiteres

Hinweis:

• in XBau 2.6 wurden UUIDs der Akteuere (Beteiligte Bauprojekt) eingeführt, war das nicht mit dem Zweck der Adressierung?

 Vergleich mit Briefpost der BAB in Richtung Bauvorhaben:

• stellt Bescheid an BH zu
• informiert den Entwurfsverfasser, dass das geschehen ist
• auch an weitere Behörden (dort ist inhaltliche Informationen enthalten)

 Diskussion zu Umsetzungsplänen des CRs:

• Nutzung der Nachricht 0100 (prozessnachrichten.aenderungProjektraumdaten.0100) - als Differenznachricht oder als Bruttonachricht?
• Idee: durch Erweiterung der Nachricht 0100 die obige Funktionalität abbilden, insbesondere Änderungen übermitteln, die im Projektraum umzusetzen sind
• Hinweis: hier aufpassen, der Use Case führt aktuell in einigen BAB zu Problemen

Status in Arbeit

Anmerkungen zum Modellierungsvorschlag im Anhang

Erweiterung ausgewählter Nachrichten um eine optionale Adressatenstruktur

Folgende Nachrichten sollen mit einer optionalen Adressatenstruktur ergänzt werden:

• 02x1, 02x3, 02x5,
• 0602,
• 0701, 0702, 0711, 0713,
• 09x1, 09x2, 09x3, 0955, (Anmerkung: statt 0903 müsste 0904 genommen werden)
• 1120, 1121, 1131, 1140, 1141, 1142, 1160

Die Ergänzung des Datentyps Nachrichtenkopf.G2G für diese Adressenstruktur (wie im Anhang vorgeschlagen) ist eher nicht passend. Dieser Datentyp ist eine Restriction auf einen Datentyp der XOEV-Bibliothek und enthält Informationen über Behörden, die als Leser oder Autor eingetragen sind.

D.h. die Ergänzung der Adressenstruktur muss hier eher in den einzelnen Nachrichten unterhalb des Elements bezug erfolgen:

0..n adressat
0..1 akteur.id (Identifier des adressierten Akteurs im Vorgang)
0..1 rolle (enthält eine Codeliste für die adressierte Rolle) → Diese Codeliste soll eine Erweiterung der Codeliste BeteiligterRolle sein

→ Frage: wieso sollen akteur.id und rolle optional an der Stelle sein?

Erweiterung Nachricht 0100 um Verarbeitungsanweisungen zu Akteuren

Im Datentyp geaenderteDaten werden folgende Kindelemente ergänzt

• antragstellerdaten
• beteiligteGeaendert/bauherr
• beteiligteGeaendert/weitereBeteiligte

um folgende Elemente:

• 1..1 akteur.id
• 1..1 verarbeitungsanweisung (enthält Codeliste VerabeitungsanweisungAenderung)
• 0..1 gültig_bis (Datentyp Datum) ->mandatorisch, wenn vearbeitungsanweisung = 03 Gültigkeit setzen. Angegeben ist der letzte Tag, an dem ein Zugriff noch möglich ist.

Die Codeliste VerabeitungsanweisungAenderung enthält folgende Einträge:

• 01 hinzufügen (Der übermittelte Akteurs-Datensatz wird als weiterer Akteur für die jeweilige Rolle im Projektraum hinterlegt. Dies ist nur dann möglich, wenn für die Rolle noch kein Akteur verzeichnet wurde oder die Definition der Rolle mehrere Akteure zulässt.) → wie lässt sich das im Projektraum sicherstellen?
• 02 ändern (Der übermittelte Akteurs-Datensatz überschreibt die Angaben zu einem bereits im Projektraum verzeichneten Akteur mit derselben akteur.id)
• 03 Gültigkeit setzen (Für einen im Projektraum bereits verzeichneten Akteur mit derselben akteurID wird ein Datum festgesetzt, nach dem dem Akteur die Lese- und Schreibrechte im Vorgang entzogen werden. Das Datum wird dem Tag gültig_bis entnommen.)

Wahrscheinlich muss statt des bisher verwendeten Datentyps BeteiligteBauprojekt im Element weitereBeteiligte ein abgeleiteter Datentyp verwendet werden.

Obige Anmerkungen treffen dann zu, falls die Nachricht 0100 mehrere Änderungen übermitteln kann.

Falls nur eine Änderung pro Versand einer 0100 Nachricht übermittelt werden darf, dann können die Elemente akteur.id , verarbeitungsanweisung und gültig_bis auf oberer Ebene ergänzt werden. Die Kindelemente müssen dann nicht geändert werden, eine Ableitung des Datentyps BeteiligteBauprojekt ist dann nicht nötig.

Neue Prozessnachricht 0110 zur Übermittlung von Informationen aus dem Projektraum

• Zur Info: Die Nachricht 0110 ist bereits belegt mit Bauberatung Anfrage.
• Die Nachricht soll lt. Anlage folgende Strukturen enthalten:
  1..1 nachrichtenkopf.g2g
  1..1 bezug
  1..1 aktuelleDaten
  1..n beteiligte
  1..1 akteur.id (Identifier des adressierten Akteurs im Vorgang)
  1..1 beteiligter
  0..1 natuerlichePerson … (Typ: xbauk:AmBauBeteiligtePerson)
  0..1 organisation … (Typ: xbauk:Organisation)
  1..1 rolle … (Typ: neue Codeliste)
  1..1 gültig_bis (Typ: Datum)
  1..1 digital_erreichbar (Typ: boolean)
  • • • • → Wozu das Element digital_erreichbar benötigt? Entweder ist diese Person jetzt im Projektraum drin (also digital erreichbar) oder sie ist nicht drin.
        • → Oder ist damit gemeint, dass durch die 0100 die Person erst eingeladen werden muss in den Projektraum? D.h. die Nachricht 01?? würde zum einen dann geschickt, wenn die Person im Projektraum angelegt wurde, und dann noch einmal wenn sie eine Einladung zum Projektraum angenommen hat?

• Lt. Anlage soll der Projektraum die Nachricht 01?? versenden:
  • sobald ein in den Projektraum eingeladener Verfahrensbeteiligter die Einladung annimmt (und damit einen digitalen Zugang eröffnet) → durch wen erhält ein Verfahrensbeteiligter eine Einladung zum Projektraum? Passiert das, wenn in der Nachricht 0100 eine neue Person hinzugefügt wird?
  • sobald die Einladung eines Verfahrensbeteiligten in den Projektraum nach Ablauf einer definierten Zeit nicht angenommen worden ist, → das ergibt nur Sinn, wenn die Einladung durch eine Nachricht 0100 angestoßen wird. Falls im Projektraum durch den Antragsteller etc. jemand eingeladen wird und dieser die Einladung nicht annimmt, muss die Behörde nicht über diese Aktion informiert werden, da sie von der Einladung eh nichts weiß.
  • sobald eine Nachricht 0100 an den Projektraum übermittelt und dort verarbeitet wurde. → werden dann alle Beteiligte übermittelt oder nur die neu angestoßenen Änderungen bestätigt?

Offene Fragen:

Wenn im Projektraum Daten von Portalseite geändert werden, müsste dann auch automatisch eine Nachricht im Sinne von 0110 gesendet werden, um die Informationen auch bei der Behörde bekannt zu machen?

• vom Projektraum muss sichergestellt werden, dass kein zwingend notwendiger Beteiligter den Zugang verliert (Antragsteller, Gebührenpflichtiger) und bestimmte Beteiligte nur einmal vorkommen (z.B. Gebührenpflichtiger)
• Die Rolle ergibt sich jetzt schon explizit (bei weiteren Beteiligten) oder implizit durch die Datenstruktur (z.B. Eintragung im Element entwurfsverfasser. Gefahr von Inkonsistenzen zwischen id und Rolle.
• Die vorhandene Codeliste BeteiligteRolle ist speziell für Rollen vorgesehen, die nicht anderweitig angegeben oder mehrfach angegeben werden können, eine Erweiterung würde der Semantik widersprechen.

Außerdem:

• Soll die Nachricht nur über Änderungen informieren, dann sollten diese auch dokumentiert werden, sonst ist der Behörde unklar, aus welchem Grund sie die Nachricht erhält.
• Oder soll ein vollständiger Satz an Beteiligten übermittelt werden?
• Sind die genannten Versendungsanlässe für die Behörde hilfreich? (sobald ein in den Projektraum eingeladener Verfahrensbeteiligter die Einladung annimmt und damit einen digitalen Zugang eröffnet, sobald die Einladung eines Verfahrensbeteiligten in den Projektraum nach Ablauf einer definierten Zeit nicht angenommen worden ist, sobald eine Nachricht 0100 an den Projektraum übermittelt und dort verarbeitet wurde)

EG26-05 10.11.2026

Diskussion zum Entwurf vom 22.10. / Umsetzungsentscheidungen:

Punkt 1 Adressierung per ID und Rolle

• wie gezeigt anhand Element adressat in Nachricht 0203
• alle im CR aufgeführten Nachrichten sollen so ausgestattet werden - dafür ist ein Datentyp notwendig
• es soll ID und Rolle alternativ sein - es ist für große Bauvorhaben notwendig (viele Entwurfsverfasser), dass auch per Rolle adressiert werden kann (“wer auch immer im Vorgangsraum die Rolle Bauherr (und ggf. Bevollmächtigter des Bauherrn) hat”) - es macht aber nur eins von beiden gleichzeitig Sinn
• Scope: Adressierung wird auf Seite Bauportal ausgewertet nur bezogen auf die aktuelle Konfiguration des Vorgangsraums - wenn Unstimmigkeit auffällt, folgt unaufgefordert ein Update an die BAB (per Nachricht 0101)
• Zugriffsregel: “auch alle zukünftigen mit der Rolle Entwurfsverfasser sollen diesen Inhalt im Projektraum sehen können”

Punkt 2 Änderung der Daten im Projektraum veranlasst von der BAB - Nachricht 0100

Prämisse: das führende Verfahren liegt bei der BAB / der Vorgangsraum gehört der BAB, sie stellt ihn bereit (“Online Zugang zu Verwaltungsleistungen”) und hat die rechtliche Hoheit, das entspricht auch dem herkömmlichen Vorgehen (ohne Bauportal) - auch das Bauportal ist ein Angebot der ÖV

Hinzufügen über die erweiterte Nachricht prozessnachrichten.aenderungProjektraumdaten.0100

• die BAB hat Anwendungsfälle, bei denen sie neue Beteiligte ins Verfahren einlädt - (ggf. im Dienst des Bauvorhabens - um das BG-Verfahren optimal zu unterstützen)
• wenn Nachricht 0100 empfangen wurde, wie lädt das Bauportal die hinzugefügte Person dann ein? die ID im Kontext des Vorgangs (wurde i.d.R. neu erzeugt für die Nachricht 0100) sagt nichts zur BundID o.ä. der Person aus; die Mail-Adresse als Merkmal der Person ist also notwendig in der übermittelten Nachricht 0100, das wäre für das Bauportal ein üblicher Weg, um Zugangsdaten zum Projektraum an die Person zu übermitteln
• auch in diesem Kontext werden Errorcodes benötigt, muss geprüft werden, was per Codeliste und was per Freitext in Fehlernachrichten eingetragen werden soll

Löschen per 0100

• es dürfen für diesen Fall nur wenige Daten in 0100-Instanz enthalten sein - Vorschlag: nur die ID; plus z.B. Familienname um die Löschung zu plausibilisieren
• gibt es ein Risiko, dass die BAB mehr Akteure löscht bzw. den Zugang zum Projektraum entzieht als es intendiert oder sinnvoll ist? ggf. sollten essentielle Beteiligte geschützt werden - das ist aber eine Funktionalität der Umsetzung im Bauportal
• auch hier: wenn es Unstimmigkeiten gibt, die beim Erhalt einer Nachricht 0100 auffallen, dann sollte das Bauportal mit einer Nachricht 0101 reagieren, um die BAB über die aktuelle Konfiguration im Vorgangsraum zu informieren
• auch in diesem Kontext: Fehlerfälle, die der BAB anzuzeigen sind
• cit: entstehen hier neue Support-Fälle, weil bestimmte Personen keinen Zugang mehr haben?

Punkt 3 Information an die BAB über die aktuelle Konfiguration im Projektraum - Nachricht 0101

• neue Nachricht prozessnachrichten.mitteilungBeteiligteImProjektraum.0101 gibt eine Liste der Beteiligten mit ihren Rollen

Status Umsetzung