Definitie van historie in RGBZ2

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

3 reacties / 0 nieuw
Maarten van den...
Definitie van historie in RGBZ2

RGBZ2 definieert nu voor een groot aantal attribuutsoorten zowel materiële als formele historie. In de implementatie is dit buitengewoon complex en ik vraag me af of er al zaaksystemen zijn die dit geïmplementeerd hebben. In een zakenmagazijn dat vanuit verschillende bronnen gevoed wordt (kan voor een zaak het geval zijn), is het voor  het correct opbouwen van de historie vereist dat elk voedend systeem zelf correct historie opbouwt. Ik vraag me af op welke termijn deze eis wordt ingevuld.

In RSGB3 is ervoor gekozen om slechts één soort historie per objecttype toe te passen, hetzij materiële, hetzij formele. Het lijkt me goed om in RGBZ2 hierbij aan te sluiten en daar uitsluitend materiële historie te definiëren. Zaaksystemen kunnen vervolgens voor zaaktypen waar zowel materiële historie als formele historie relevant is deze voor die zaaktypen opbouwen. Als je vanuit een zakenmagazijn dit wilt weten, dan zal je dus het zaaksysteem dat de zaak heeft opgebouwd moeten raadplegen.

Arjan Kloosterboer

In RGBZ 1 is er bewust voor gekozen om soms informatie over zowel materiele als formele historie te kunnen verkrijgen. In RSGB 3 is van formele historie afgezien omdat informatie daarover uit landelijke voorzieningen te verkrijgen is. Bij zaken zijn dergelijke voorzieningen er niet. Door bij een attribuut- of relatiesoort beide histories te specificeren (in een conceptueel informatiemodel), geven we aan dat informatie over beide histories te verkrijgen moet zijn uit de gemeentelijke informatievoorziening cq. uit de registratie waarin zich de desbetreffende zaak bevindt. We kunnen er voor kiezen om in een op uitwisseling gericht informatiemodel één van beide histories niet op te nemen. Die wordt dus niet uitgewisseld, maar moet wel beschikbaar zijn. Daarmee leggen we de verplichting op dat informatie over die andere historie te verkrijgen moet zijn uit de registratie waarin de zaak onderhouden wordt.  

Het lijkt mij al met al dus een implementatiekeuze voor het uitwisselingsmodel (i.c. StUF-ZKN). Schrappen uit het conceptuele model (i.c. RGBZ) zou betekenen dat informatie over die ene historie niet beschikbaar zou hoeven zijn. En da's nou ook weer niet de bedoeling.

Henri Korver

Dank voor de uitleg Arjan. Het is voor mij nu duidelijk waarom in het SIM RGBZ beide histories behouden moeten blijven. In het UGM BG kunnen we eventueel één van de histories schrappen om de gegevensuitwisseling te vereenvoudigen. Ik neem aan dat we in het UGM ZKN de formele historie zullen schrappen, maar dat zal natuurlijk nog overlegd moeten worden met de StUF Expertgroep.