Cocreatie:Denk mee met Omgevingswet

Over dit discussiebord

Als u wil mee discussiëren, gebruik dan deze pagina. Kijk op de pagina forumfunctionaliteit, om te zien hoe de forumfunctionaliteit werkt.

De discussie gaat over het onderwerp dat start bij de pagina: Thema Omgevingswet

Door op "Onderwerp toevoegen" te klikken gaat u akkoord met de gebruiksvoorwaarden van deze wiki.

binnengemeentelijke standaarden

1
Dmoree (Overlegbijdragen)

Bij de binnengemeentelijke interactiepatronen (2,4,5,6,7,8) staan nog weinig standaarden aangegeven. Wordt dat binenkort nog verder uitgewerkt?

csv's met requirements

1
Dmoree (Overlegbijdragen)

Kunnen alle requirements svp in 1 csv? Voor alle drie de Applicatie-deelgebieden.

Jan van Langeveld (Overlegbijdragen)

Het betreft het kunnen genereren van brieven/besluiten van de VTH-component. Ik neem aan dat hier het creëren van documenten wordt bedoeld. Deze requirement van de VTH-component is dan 'dubbel' omdat het documentcreatiecomponent al daarvoor bedoeld is. Moeten de requirement niet omschrijven naar 'het uitwisselen van informatie naar het documentcreatiecomponent zodat brieven te genereren zijn'?

Jan van Langeveld (Overlegbijdragen)

De requirement gaat over het kunnen uitwisselen van gegevens met het Vergunningen-en-meldingenregistratie component. Is essentieel. Dit blijkt een 'should'. Waarom? De toelichting geeft geen verdere toelichting van de prioriteit, maar spreekt wel over een noodzakelijk voor toezicht en handhaving.

Toepasbareregelscomponent

Eén reactie • 5 jun 2019 14:01 5 juni
1
Jan van Langeveld (Overlegbijdragen)

Requirement TR40 Kunnen realiseren van een eigen 'loket' voor checken en oriënteren is nu gekoppeld aan dit component. Het TR40 requirement kent een ander doel, namelijk checken en oriënteren, dat afwijkt van het doel van toepasbare regels: het opstellen van toepasbare regels. Ik zou verwachten dat dit requirement is gekoppeld aan een ander component dat dus beter past bij het doel (bijvoorbeeld het gemeentelijkomgevingswetloketcomponent).

Publicatiecomponent binnen omgevingsbeleidscomponent

Eén reactie • 5 jun 2019 13:24 5 juni
1
Jan van Langeveld (Overlegbijdragen)

Ik lees dat dit component voor de publicatie en het archiveren bedoeld is (zie req. OBP08 uit set versie 1.0). Dit klopt niet. Het archiveren van wijzigingsberichten moet binnen de eigen gemeentelijke informatievoorziening plaatshebben. Dit is een eis uit de Archiefwet. De LVBB is daarom niet bedoeld als archief, maar wel bedoeld als GDI-voorziening voor het bekendmaken en beschikbaar stellen van wijzigingsbesluiten. De Gemma bevat al het referentiecomponent 'Archiefbeheercomponent' met deze requirement. Daar ontstaat een dubbelling met het doel van dit publicatiecomponent (ook bedoeld voor het archiveren). Er is dus een interactiepatroon tussen het publicatiecomponent (voor sec het publiceren) en het archiefbeheercomponent (voor het archiveren).

Specifiek procesafhandelingscomponent, generiek

7
Jan van Langeveld (Overlegbijdragen)

Wat wordt de rol van het procesafhandelingscomponent? In de onderlinge gegevensstromen met het DSO-LV, de LVBB en tussen de DSO-CG componenten voor Omgevingswet gaat het voor 'de flow' om het inregelen van de noodzakelijke procesafhandeling tussen componenten en het ordenen van het bijbehorende API-verkeer. Binnen de Gemma 2.0 is daar destijds het 'specifieke procesafhandelingscomponent' voor in het leven geroepen. Dit procesafhandelingscomponent was toen verbonden met het vergunningen- en zaakcomponent (Gemma 2). Is dit nog wel zo specifiek? Ik denk het component ook een rol zal spelen tussen andere Ow componenten, zoals het omgevingsbeleidcomponent. Flow is dus geen eigenschap van elk Ow component en sich, maar is toegekend aan een generiek procesafhandelingscomponent.

Tschijv (Overlegbijdragen)

Welk component bedoel je precies en op welke pagina heeft het betrekking? Kan je dat als reactie hierop met een link erbij zetten?

Jan van Langeveld (Overlegbijdragen)

Het component staat hier. https://www.gemmaonline.nl/index.php/Omgevingswet/1.5/id-7a855337-fcbb-11e5-11ba-005056a85f9c

Jan van Langeveld (Overlegbijdragen)

De procesafhandeling per component is complexiteitsverhogen. De specialisatie zoals nu aangegeven is niet gebaseerd op de hoeveelheid flows die reeds in de Omgevingswet zijn onderkend. Volgens mij gaat het om een eigenstandige applicatiefunctie die toebehoord aan een eigen referentiecomponent. Ik pleit niet voor een federatieve opzet van diverse procesbesturende Zaak- , VTH-, planapplicaties. Hoe gaan we die flows vanuit 'servicesformules' managen? Ik verwacht dat er behoefte is centrale controle op regie van de flows.

Tschijv (Overlegbijdragen)

Wellicht is de bedoeling van dit abstracte component niet duidelijk. Daarmee modelleren we functionaliteit voor meerdere referentiecomponenten (handig voor de modelleur). De bedoeling is dat deze functies (fysiek) bij de desbetreffende referentiecomponent terecht komt en niet in een apart component, zoals je dat nu interpreteert, dat dan als apart component zou moeten worden ingezet. We zullen er meer toelichting zij zetten, zodat dit ook duidelijk omschreven is.

Jan van Langeveld (Overlegbijdragen)

Weet niet of dat de juiste aanpassing is vanwege mij pleidooi. Ik pleit voor een '(procesorkestratie)flowcomponent' zoals we dat ook bij de gemeente Den Haag positioneren om grip te houden op allerlei gebeurtenissen in onze Ow zaakbehandelketens ('van idee tot afhandeling, 'plan tot publicatie' of 'vraag naar informatie'). Dit component is nu ook al in onze vergunningketen ingevoerd (gekoppeld aan de API-gateway en het OLO). Door de Omgevingswet kan het breder toegepast worden bij flow management bij de andere twee ketens.

Tschijv (Overlegbijdragen)

Hoewel niet in eerste instantie zo bedoeld kan een dergelijk abstract component ook als generiek fysiek component worden gezien die die generieke functionaliteit ondersteunt voor diverse backoffice systemen die deze functionaliteit (nog) niet hebben. Goed idee om dit als mogelijkheid aan de beschrijving toe te voegen.

Plannen en prioriteren van toezicht

3
Hans Pluimers (Overlegbijdragen)

Het plannen en prioriteren van toezicht wordt een steeds belangrijkere taak voor toezichthoudende instanties (en dus ook voor gemeenten en Omgevingsdiensten).

Hiervoor wordt vaak een component die onderdeel uitmaakt van een VTH-applicatie ingezet maar gelet op het opsplitsen van de functionaliteit zoals die nu is uitgewerkt lijkt het verstandig om deze component ook apart te benoemen.

De input voor deze component zal uit de registratiecomponent voor VTH-objecten en de resultaten van uitgevoerd toezicht moeten komen. Het resultaat van deze component zal bestaan uit een set geagendeerde controlezaken met bijbehorende VTH-objecten.

Is het logisch om deze component apart te benoemen?

Tschijv (Overlegbijdragen)

Zou het ook een functie kunnen zijn van het Toezichtafhandelcomponent kunnen zijn?

Hans Pluimers (Overlegbijdragen)

dat lijkt mij niet. Het plannen en prioriteren van toezicht is een functie die geheel los staat van de afhandeling van toezicht. Het is een functie die op basis van een analyse van (VTH) data een set "toezichtzaken met daaraan gekoppelde toezichtobjecten' klaarzet. Dat heeft dus meer te maken met het voorbereiden van toezicht (op welke objecten ga ik toezicht houden) dan met het afhandelen van toezicht.

Hans Pluimers (Overlegbijdragen)

Vanuit de dagelijkse praktijk zijn er 5 belangrijke routes om VTH-zaken te agenderen: 1. als vervolg op een vergunningzaak of een meldingzaak (dus het agenderen van een zogenaamde opleveringscontrole); 2. als vervolg op een melding overlast (dus het agenderen van een zogenaamde inventariserende controle); 3. als vervolg op een eerdere controle (dus het agenderen van een hercontrole op basis van een gekozen (handhaving)strategie); 4. het vertalen van het resultaat van een doorgerekend prioriteringsmodel naar een set met te agenderen periodieke controles (voor milieu, brandveilig gebruik en activiteiten die gedurende een langere periode of permanent worden uitgevoerd). 5. het vertalen van het resultaat van een doorgerekend prioriteringsmodel naar een set met te agenderen themacontroles (voor alle VTH-objecten waarvoor thematisch toezicht kan bijdragen aan het behalen van de beoogde beleidsdoelstelling).

Tschijv (Overlegbijdragen)

Waar hoort deze opmerking bij? Is dit een voorstel voor uitbreiding van de GEMMA functie: Agenderen van zaken? Zie: https://www.gemmaonline.nl/index.php/GEMMA2/0.9/id-fd460824-e70a-11e1-7023-0050568a1905 ?

Hans Pluimers (Overlegbijdragen)

Het gaat er mij/ons om dat het agenderen van zaken (op basis van een analyse van de beschikbare data van VTH-objecten) een onderdeel is of moet zijn van de functies van een VTH-applicatie. Aangezien de criteria om die zaken te agenderen heel VTH-specifiek zijn (en er bij het aanmaken van VTH-zaken relatie moet worden gelegd met de VTH-registraties, kan (in onze ogen) niet worden volstaan met een generieke functie maar is dit een specifieke VTH-functie.

Registratie en behandeling meldingen overlast in het kader van de Omgevingswet

2
Hans Pluimers (Overlegbijdragen)

Ik mis nog een registratie en behandelcomponent voor de meldingen van overlast in het kader van de Omgevingswet.

Dit klachten komen vaak binnen bij een omgevingsdienst en worden dan in overleg met het betreffende bevoegd gezag onderzocht en afgehandeld.

Aangezien deze component(en) ook relevant zijn in het kader van ketensamenwerking lijkt het logisch om die component ook op te nemen in het overzicht.

Tschijv (Overlegbijdragen)

Die staan hier inderdaad niet bij. Dit moet voor een belanghebbende een component zijn om overlast te melden, in GEMMA hoort dat bij het Klachten- en meldingencomponent, zie: https://www.gemmaonline.nl/index.php/GEMMA2/0.9/id-d2d0679e-1fe3-4ec3-9b56-e11d693d1408