Om gereed te zijn voor de invoering van de Omgevingswet in 2024 moet een gemeente een aantal wijzigingen doorvoeren in de gemeentelijke informatievoorziening. In deze katern onderzoeken we welke functionaliteit de gemeentelijke applicaties in 2024 nodig hebben om de Omgevingswet goed te kunnen uitvoeren.
Met deze applicatie-architectuur ondersteunen we gemeenten bij het voor de Omgevingswet aanpassen van hun informatievoorziening. De architectuur beschrijft de voor de Omgevingswet benodigde informatievoorziening op drie aspecten: de benodigde referentiecomponenten (applicaties), de requirements die we stellen aan deze componenten en de koppelvlakken en informatie-uitwisseling tussen de componenten.
Met deze katern kan een gemeente zelf keuzes maken hoe zij de gemeentespecifieke informatievoorziening inrichten. Waarbij de requirements uiteindelijk gebruikt kunnen worden voor het selecteren van geschikte applicaties.
Om tot een concrete beschrijving van de componenten te komen, betrekken we zowel gemeenten als gemeentelijke softwareleveranciers in het opstellen van deze katern. Net als de DSO-LV kiezen wij bij het opstellen van deze katern voor een Agile aanpak. Dit betekent dat we in korte iteraties met het document op basis van geleverde input naar een volgende versie brengen. Dit geeft een ieder de mogelijkheid om mee te denken en te schrijven. Het betekent ook dat de katern voorlopig nog geen definitieve status heeft en daarmee ook als zodanig dient te worden gelezen.
Deze katern beschrijft de voor de uitvoering van de Omgevingswet gewenste applicatie functionaliteit. Hierbij gaan we per onderdeel van het document een stapje dieper de details in. Van uitgangspunten tot applicatie requirements en applicatie koppelvlakken. Dit leidt tot de volgende opbouw:
Uitgangspunten en principes: als basis voor de applicatiefunctionaliteit gebruiken we bestaande architectuurmodellen zoals de GEMeentelijke Model Architectuur (GEMMA).
De referentiecomponenten voor de Omgevingswet: we geven een overzicht en beschrijving van de GEMMA-referentiecomponenten die benodigd zijn voor de uitvoering van de Omgevingswet. Hierbij maken we onderscheid tussen componenten die op termijn vervangen worden, nieuw zijn of impact ondervinden. Op basis van een analyse van de Omgevingswet processen zien we drie groepen applicatiecomponenten ontstaan: een groep die het Omgevingsbeleid ondersteunt, een groep voor de VTH-processen en een overige categorie met o.a. het Bestuur en Raadsinformatie systeem en het gegevensmagazijn.
Requirements Omgevingsbeleidscomponenten geeft inzicht in de requirements voor de eerste groep Omgevingswetreferentiecomponenten, de Omgevingsbeleidcomponenten.
Koppelingen voor de Omgevingswet brengt op de uitwisseling van gegevens tussen applicatiecomponenten in beeld, zowel binnen de gemeente als tussen de gemeente en DSO-LV en GDI bouwstenen. We definiëren de koppelvlakken en laten de informatiestromen tussen de koppelvlakken zien.
Let op dat hier heel duidelijk de Common Ground implicatie ‘Procesafhandeling en Gegevensverwerking strikt gescheiden en met API’s ontsloten’ zichtbaar wordt. Daarnaast is ook duidelijk te zien dat de procesafhandeling met name in het VTH-domein ook tot aparte referentiecomponenten heeft geleid omdat werkwijzen, doelgroep en applicatiegebruik duidelijk afwijken.
De granulariteit van de requirements loopt nog wat uiteen. In een volgende versies wordt bekeken hoe de requirements zich tot elkaar verhouden.
Dit betreft een eerste aanzet voor de functionaliteit bedoeld om de discussie hierover te vergemakkelijken.
Op GEMMA Online staat altijd de laatste versie. Er worden dus geen versienummers toegekend aan diverse onderdelen of het geheel. In de totstandkoming van dit katern is met een aantal gremia overleg geweest om tot dit kader te komen.
Updates aan omgevingsbeleidsrequirements waardoor deze aansluiten bij STOP 0.96b
Nieuwe componenten toegevoegd / uit GEMMA overgenomen: omgevingsbeleidviewer, digitaal ontwerpencomponent (CAD) en participatie component, informatieproductenbeheer component en informatieproductenregistratie component.
Updates van interactiepatronen (o.a. wijzigen omgevingsplan)
Nieuw interactiepatroon voor gebruik lokaal informatieproduct in DSO-LV omgevingsloket
1.0 / juni - juli 2020
Wiki geüpdated met aangepaste views
Tekstuele aanpassingen doorgevoerd i.v.m. nieuwe datum inwerkingtreding
De GEMMA biedt allerlei handvatten voor de informatievoorziening van gemeenten. Deze worden ook hier gebruikt, waar van toepassing. Dit geldt enerzijds voor de architectuurprincipes, zoals beschreven op GEMMA Online. Deze principes zijn:
De Omgevingswet staat voor integraal en zaakgericht werken. Dit is zo afgesproken in het bestuursakkoord. De minimale variant hiervan is het uitgangspunt dat we in het kader van de Omgevingswet minimaal zaakgericht registreren zoals beschreven in het GEMMA Katern Zaakgericht Werken.
Uitvoering van omgevingswettaken vindt, daar waar meerdere partijen betrokken zijn, plaats in procesketens (ketens van processen). Iedere organisatie voert haar eigen bedrijfsproces uit. Deze bedrijfsprocessen vormen gezamenlijk een procesketen gericht op bijvoorbeeld de behandeling van een vergunningaanvraag of de aanpassing van een omgevingsplan.
In het bestuursakkoord is afgesproken dat de samenwerking in deze procesketen zaakgericht plaatsvindt. Dat betekent dat er sprake is van een keten van bedrijfsprocessen die, vanuit de procesketen gezien, zich gedraagt als een keten van zaken. Kenmerkend hierbij is dat elke zaak zich afspeelt binnen één organisatie cq. bij één ketenpartner (ondersteund door haar eigen informatiesystemen). Of een ketenpartner daadwerkelijk haar bedrijfsprocessen zaakgericht uitvoert, is niet direct relevant. Van belang is daarentegen wel dat tussen de ketenpartners zaakgericht gecommuniceerd en afgestemd wordt (ook al werkt niet iedereen zaakgericht) om uitvoering te geven aan een procesketen zoals bijvoorbeeld die aanvraagbehandeling of die aanpassing. In de ketensamenwerking is dus de afspraak dat de betrokken ketenpartners minimaal doen alsof zij zaken uitvoeren, zaken die aan elkaar gerelateerd zijn. (citaat Rapportage UIVO-i-onderzoek Informatie-architectuur Samenwerking versie 1.0).
Een verder uitwerking van de relatie processen en zaakgericht werken is na te lezen in de GEMMAProcesarchitectuur.
In het Digitaal stelsel omgevingswet is ook aan aantal principes geldig die we meenemen als uitgangspunten voor de relatie van DSO-LV met de gemeentelijke informatievoorziening. De NORA principes die daaraan vooraf gaan zien we als een gegeven en net als bij de GEMMA principes zijn deze bij de betreffende architectuur na te lezen.
De DSO-LV principes zijn:
op bedrijfsarchitectuurniveau
Eén stelselorganisatie voert regie op het digitaal stelsel (APDSO01)
De stelselorganisatie ondersteunt het beantwoorden van vragen over de werking van het digitaal stelsel (APDSO02).
Eindverantwoordelijkheid samengestelde omgevingsinformatie is belegd (APDSO02a).
Leveranciers van omgevingsinformatie hergebruiken gegevens (APDSO02b).
op informatiearchituurniveau
Het digitaal stelsel is modulair opgebouwd (APDSO03).
Onderdelen en functies zijn ontkoppeld (APDSO04).
Hergebruik voor kopen en maken (APDSO05).
Gebruikerstoepassingen zijn voor de gebruikers in één loket ontsloten (APDSO06).
Alle omgevingswetdocumenten worden op één punt aangeleverd en afgenomen (APDSO07).
Bevoegd gezagen leveren omgevingswetdocumenten en toepasbare regels aan (APDSO08).
Op basis van de GEMMA-Omgevingswetprocessen is een onderzoek gedaan naar welke gemeentelijke applicaties worden gebruikt binnen de fysieke leefomgeving en waar de Omgevingswet mogelijk invloed op gaat hebben. Deze zijn ingedeeld op referentiecomponenten die:
op termijn vervangen worden, nieuw zijn of sterk gewijzigd gaan worden (tabel 1);
In de volgende drie hoofdstukken zoomen verder in op de drie belangrijkste verzamelingen van componenten, 1) de Omgevingsbeleidcomponenten, 2) de Regelbeheercomponenten en 3) de VTH-componenten. Hierbij onderzoeken we welke requirements en koppelingen de componenten dienen te omvatten voor de uitvoer van de Omgevingswet. Vervolgens brengen we onder Koppelingen voor de Omgevingswet in beeld op welke manier via deze koppelingen informatie binnen de gemeente of tussen de gemeente en DSO-LV dan wel een GDI voorziening wordt uitgewisseld.
Onderstaande afbeelding en tabel geven een overzicht van de referentiecomponenten die de Omgevingswet processen ondersteunen. Deze selectie componenten is zoals aangegeven ontstaan na een analyse van de Omgevingswet processen. Deze processen zijn te vinden onder de Bedrijfsarchitectuur omgevingswet. De views gebruikt voor de analyse van processen en componenten zijn te vinden onder Bijlage Omgevingswetprocessen en referentiecomponenten.
Component voor het ontwikkelen, beheren en digitaal beschikbaar stellen van omgevingsdocumenten (omgevingsplan, omgevingsvisie en programma) conform de Omgevingswet standaarden. Hiermee is de Omgevingsbeleid component de opvolger van de GEMMA WRO-component. De Omgevingsbeleidcomponent bevat diverse functionalteiten voor omgevingswetbesluiten (voorbereidingsbesluiten).
Component voor het beheren en digitaal beschikbaar stellen van toepasbare regels op basis van de regels uit beleid (omgevingsvisie, programma, omgevingsplan)
Component voor het ondersteunen van diverse soorten vergunningverlening, het ondersteunen op het toezicht houden en het ondersteunen van het handhaven.
Component voor het ontwikkelen, beheren en digitaal beschikbaar stellen van digitale ruimtelijke plannen conform de Wet ruimtelijke ordening (Wro). Onder de Wet ruimtelijke ordening (Wro) dienen alle Wro instrumenten (planologische visies, plannen, besluiten, verordeningen en algemene maatregelen van bestuur) digitaal vervaardigd en digitaal beschikbaar gesteld te worden
De onderstaande tabel geeft een overzicht van de referentiecomponenten die minder sterk wijzigen, maar waar de Omgevingswet wel een bepaalde impact op heeft.
Tabel 2: Overzicht van alle bestaande referentiecomponenten in het gemeentelijk domein die betrokken zijn en waar Omgevingswet mogelijk invloed op heeft
Component voor ondersteuning van het proces van innen, invorderen en kwijtschelden van publiekrechtelijke en eventueel ook privaatrechtelijke vorderingen.
Op deze pagina bieden we in tabelvorm en ter download de requirements (specificaties) aan voor de omgevingsbeleidsoftware per 2024. Requirements geven inzicht in de wensen en eisen die we stellen aan software. De requirements zijn bedoeld voor gemeenten die zich oriënteren op nieuwe software voor omgevingsbeleid dan wel een aanbesteding gaan doen. Ze helpen de inhoudelijk specialisten (o.a. juristen, regelanalisten en vergunningverleners), medewerkers van ICT (functioneel beheerders en informatiemanagers) en specialisten van inkoop en aanbesteding om gezamenlijk een beeld te vormen van de aan te besteden software.
De requirements worden met input van gemeenten en softwareleveranciers iteratief opgesteld. De onderstaande versie betreft de 1.5.1 versie. Dit is een stabiele versie die een gemeente kan gebruiken bij het selecteren van software voor omgevingsbeleid. Gezien de ontwikkelingen binnen het Digitaal Stelsel Omgevingswet, weten we dat de eisen die we aan de software stellen nog worden aangepast. Denk hierbij aan de ontwikkeling van de standaard voor publiceren (STOP) en het Toepassingsprofiel Omgevingsdocumenten (TPOD).
Per versie worden er releasenotes als ODS-bestand ter download beschikbaar gesteld, waarin de verschillen tussen de vorige versie en de nieuwe versie naast elkaar worden weergegeven. Lees vooraf het tabblad waarop de instructies staan.
Wil een gemeente starten met een aanbesteding, dan bieden deze requirements een goede basis voor die aanbesteding. Wil je meer weten over de verschillende manieren van aanbesteden en op welke wijze je de daarbij requirements gebruikt? VNG heeft een Handreiking Aanbesteden.
Naar verwachting zullen de meeste leveranciers aan de belangrijkste requirements gaan voldoen (zie ook onderstaande indeling in categorieën). Dit zorgt er voor dat je qua functionaliteit als gemeente niet snel een "foute" keuze kan maken. Toch zullen de leveranciers op onderdelen gaan verschillen. Om hier inzicht in te verkrijgen zullen op deze site en in de handreiking ook vragen verschijnen waarmee een gemeente die inzicht kan verkrijgen. Denk hierbij aan vragen als: Op welke manier zal de leverancier de workflow voor het opstellen van een omgevingsplan ondersteunen? Of op welke manier gaat de leverancier ondersteuning bieden aan het koppelen van juridische en toepasbare regels?
Met de requirements en de leveranciersvragen biedt VNG aan gemeenten een uniforme manier van uitvragen van de software voor toepasbare regels. Een uniforme manier van uitvragen is essentieel om komende periode van implementatie succesvol te laten verlopen. Softwareleveranciers staan al onder druk om in 2023 werkende software te kunnen leveren. Als iedere gemeente op haar eigen manier met eigen requirements de software gaat aanbesteden, levert dit voor de softwareleveranciers veel werk op. De tijd die ze daarmee besteden aan het meedoen met de aanbesteding, kunnen ze niet gebruiken om de software te ontwikkelen. Door op een als gemeenten op een uniforme wijze aan besteden, zorgen we er voor dat leveranciers kunnen focussen de ontwikkeling van software.
We hanteren de volgende categorieën voor de requirements, die meer in lijn liggen met de ‘Minimale acties Omgevingswet’. De requirements zijn onderverdeeld in drie categorieën:
Must Have: Deze functionaliteiten zijn noodzakelijk om de wet uit te kunnen voeren op het moment dat de wet in werking treedt. Het gaat om functionaliteiten om aan te kunnen sluiten op DSO-LV en andere verplichte landelijke voorzieningen en om functionaliteiten om essentiële processtappen uit te kunnen voeren. Functionaliteiten in deze categorie zijn in alle gevallen ‘Must Have’. Voorbeelden hiervan zijn, het kunnen produceren van een omgevingsplan in STOP-formaat en het kunnen publiceren van dit plan naar LVBB, het kunnen ophalen van een vergunningaanvraag in STAM-formaat en het kunnen verlenen van een omgevingsvergunning.
Should Have: Deze functionaliteiten zijn gezien vanuit het wettelijke minimum niet noodzakelijk om de wet uit te kunnen voeren, maar volgens VNG wel essentieel voor een adequate uitvoering. Deze functionaliteiten zijn volgens VNG minimaal ’Should Have’. U kunt besluiten om enkele van deze functionaliteiten als ‘Must Have’ te bestempelen als u ze voor uw eigen situatie noodzakelijk acht. Een voorbeeld van een functionaliteit in deze categorie is functionaliteit voor het aansluiten op de samenwerkingsfunctionaliteit van DSO-LV. Deze aansluiting is niet verplicht, maar wel essentieel om binnen de wettelijke termijn een vergunningaanvraag in samenwerking met andere partijen af te kunnen handelen.
Onbepaald: Deze functionaliteiten zijn niet noodzakelijk vanuit het wettelijke minimum of essentieel voor een adequate uitvoering. VNG kan daarom aan deze functionaliteiten geen belang toekennen. U dient zelf te bepalen hoe gewenst deze functionaliteiten voor situatie is. VNG raadt aan om deze softwarerequirements te internaliseren voordat u ze gebruikt bij het definiëren van een PvE voor uw software door uw lokale situatie te vertalen in ‘must haves’, ‘should haves’, ‘could haves’ en ‘won’t haves’.
VNG raadt aan om deze softwarerequirements te internaliseren voordat u ze gebruikt bij het definiëren van een PvE voor uw software door uw lokale situatie te vertalen in ‘must haves’, ‘should haves’, ‘could haves’ en ‘won’t haves’. Ga na welke softwarerequirement voor u van toepassing is en ga na of de hier aangegeven categorie ook bij u van toepassing is.
Requirements die niet meer gelden, zijn uit de lijst weggehaald. In de Releasenotes die horen bij deze versie is terug te vinden welke requirements nieuw zijn, welke requirements zijn aangepast en welke requirements zijn vervallen.
Doorontwikkeling applicaties: Na de inwerkingtreding van de Omgevingswet zal de software voor omgevingsbeleid zich verder ontwikkelen. Gemeenten hebben hierbij aangegeven dat ze graag zien dat de software gaat voldoen aan Common Ground en dat de gehele beleidscyclus (van visie, naar plan, vergunning verlening, toezicht, handhaving en evaluatie) wordt ondersteund met integrale software.
De Omgevingsbeleidcomponent bevat applicatiefuncties die benodigd zijn voor het opstellen van beleid voor de Omgevingswet. Denk hierbij aan het wijzigen van het omgevingsplan of het maken van een omgevingsvisie.
Modulaire opzet: De omgevingsbeleidcomponent bestaat uit een component met functies gericht op omgevingsbeleid en een component gericht op viewer functionaliteit. De viewercomponent kan onderdeel zijn van de omgevingsbeleidcomponent, maar kan ook als los component ingezet worden. Het is aan de gemeente om te kiezen op welke manier zij de componenten willen aanschaffen.
Omgevingsplan uitbesteed aan een bureau? Met de modulaire opzet ondersteunen de requirements zowel gemeenten die zelf hun omgevingsplan gaan onderhouden, als gemeenten die deze taak uitbesteden aan een bureau. Een gemeente die het wijzigen van haar plan uitbesteedt, zal vermoedelijk voldoende hebben aan de viewercomponent. Waarbij een gemeente die haar plannen zelf maakt, de gehele omgevingsbeleidcomponent en mogelijk ook de viewercomponent zal gebruiken.
Onderstaande tabellen tonen de requirements per applicatiefunctie.
Overzicht requirements per applicatiefunctie (uit model: Omgevingswet) - Toon SVG - Download als csv
De opgenomen requirements kunnen per applicatiefunctie als CSV bestand worden gedownload. Deze bestanden kunt u gebruiken bij het opstellen van een Programma van Eisen.
In onderstaande tabellen wordt onderscheid gemaakt in welke requirements verplicht zijn bij de inwerkingtreding (MUST), welk requirements door VNG worden geadviseerd (SHOULD) en welke requirements aanvullende functionaliteit bieden (ONBEPAALD).
Onderstaande tabel toont alle requirements die gelden voor de Omgevingsbeleidcomponent met de categorie MUST. De Omgevingsbeleidcomponent moet bij de inwerkingtreding van de Omgevingswet voldoen aan onderstaande requirements.
Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB waardoor de specificaties van de release nog kunnen wijzigen tot de datum van inwerkingtreding.
Het opnemen van een instructie ten behoeve van de 'pons' valt ook onder Release A.
Het kunnen ophalen van geometrie uit de Basisregistratie Grootschalige Topografie (BGT), Basisregistratie Adressen en Gebouwen (BAG) en Basisregistratie Kadaster (BRK) en gemeentelijke Kernregistraties.
Kunnen detecteren van de verschillen (op basis van de STOP-TPOD) tussen oude en nieuwe versies van de lopende regeling (tekst, annotaties en geometrie) (was-wordt).
Kunnen genereren van een was/wordt instructie welke aan het wijzigingsbesluit wordt toegevoegd.
Wijzigingen kunnen geselecteerd worden tot één wijzigingsbesluit.
Toelichting:
Met deze instructie wordt in de landelijke voorziening het verschil tussen de huidige en nieuwe versie duidelijk gemaakt waardoor de landelijke voorziening een geconsolideerde versie kan maken.
De was/wordt instructie wordt gebruikt ten behoeve van de aanlevering aan de raad en college en aan de landelijke voorziening.
Aangepast in versie 1.5: toevoeging 'ten behoeve van publicatie' verwijderd.
Aangepast in versie 1.4.1: In requirementnaam ‘van’ toegevoegd
Was: Kunnen genereren van was/wordt instructies. Is in versie 1.4 geworden: Kunnen genereren van was/wordt instructies ten behoeve publicatie
Kunnen valideren van wijzigingsbesluit via het LVBB Bronhouderkoppelvlak aan de vereisten uit STOP-TPOD release A.
Toelichting:
Tekst aangepast in versie 1.3. Was kunnen valideren van besluit. Is geworden: kunnen valideren van regeling.
Tekst aangepast in versie 1.4. Was kunnen valideren van regeling. Is geworden: Kunnen valideren van wijzigingsbesluit ten behoeve van publicatie.
Requirementnaam aangepast in versie 1.5: Was: Kunnen valideren van wijzigingsbesluit ten behoeve van publicatie. Is geworden: Kunnen valideren ten behoeve van aanlevering
Kunnen ondersteunen van voorkomen van fouten door wijzigen van zelfde artikel door verschillende medewerkers (interne samenloop).
Kunnen bieden van inzicht aan gebruiker van elkaars werkzaamheden.
Kunnen samenvoegen van wijzigingen.
Toelichting:
Requirement geupdate in versie 1.2: van should naar must
Tekst aangepast in versie 1.4. Was: Kunnen ondersteunen van tegelijk werken aan plan binnen organisatie. Is geworden: Kunnen ondersteunen van tegelijk werken aan (lopende) regeling.
Kunnen overnemen, in de lopende regelingversie, van wijzigingen in een (door bijvoorbeeld een stedenbouwkundig adviesbureau), in STOP/TPOD, aangeboden regeling door organisaties die het maken van hun omgevingsplan uitbesteden.
Kunnen ondersteunen van het voorkomen van fouten door wijzigingen, in de aangeboden regelingversie, die conflicteren met de lopende regelingversie.
Aangepast in versie 1.4.1: Typefouten uit toelichting verwijderd
Nieuw requirement in versie 1.4, heeft betrekking op de zgn. plan-plan-keten
Het kunnen uitvoeren van regeling- en besluitannotaties, bijvoorbeeld de naam van het bevoegd gezag dat het omgevingsplan heeft vastgesteld en de datum waarop de versie van het omgevingsplan is gepubliceerd
het kunnen uitvoeren van tekststructuurannotaties, bijvoorbeeld het nummer en de
titel van het structuurdeel (hoofdstukken, afdelingen en paragrafen)
het kunnen uitvoeren van artikelen-, leden- en regeltekstannotaties, bijvoorbeeld het
nummer en de titel van het artikel, het lidnummer en inhoudelijke annotaties van de tekst van
artikel en lid, zoals werkingsgebied
het kunnen annoteren van inhoudelijke regeltekstannotaties, bijvoorbeeld activiteit, norm, normwaarde, locatie, gebiedsaanwijzing, thema, regeltype, idealisatie en activiteitkwalificatie.
Toelichting:
Onder annoteren wordt verstaan het toevoegen van gegevens aan (onderdelen van) besluiten en regelingen, gegevens die die besluiten en regelingen machineleesbaar maken.
Annoteren is afgebakend tot de kenmerken genoemd in het Informatiemodel Officiële Publicaties (IMOP) en in het Informatiemodel Omgevingswet (IMOW).
Kunnen tonen van iedere status (concept, ontwerp, vastgesteld) van de regeling (omgevingsvisie, omgevingsplan, programma, voorbereidingsbesluit) op een kaart op basis van STOP-TPOD presentatiemodel;
Kunnen tonen van wijzigingen in regeling op een kaart op basis van STOP-TPOD presentatiemodel.
Kunnen tonen van wijzigingen voor één wijzigingsbesluit op basis van STOP-TPOD presentatiemodel.
Toelichting:
Toelichting aangepast in versie 1.5
Aangepast in versie 1.4.1: Typefoutren uit toelichting verwijderd
Tekst aangepast in versie 1.4
Requirementnaam aangepast van 'omgevingsbeleid' naar 'regelingen en wijzigingen' in versie 1.4
Kunnen tonen van iedere status (concept, ontwerp, vastgesteld) van de regeling (omgevingsvisie, omgevingsplan, programma, voorbereidingsbesluit) als tekst op basis van STOP-TPOD presentatiemodel;
Kunnen tonen van wijzigingen in regeling als tekst op basis van STOP-TPOD presentatiemodel.
Toelichting:
Tekst aangepast in versie 1.4
Requirementnaam aangepast van 'omgevingsbeleid' naar 'regelingen en wijzigingen' in versie 1.4
Kunnen inzien van oude, huidige en nieuwe regelingen.
Kunnen inzien van de geldende regels op een te kiezen datum.
Kunnen zien van verschillen (wijzigingen) in regelingen tussen alle vorige versies van de regeling.
Toelichting:
Zelfde requirement als regelingcomponent, maar dan voor de viewercomponent. Hier opgenomen zodat een organisatie die haar plan uitbesteed voldoende heeft aan alleen een publicatie- en viewercomponent.
requirments geupdate in versie 1.1.
Geupdate in versie 1.3. Toegevoegd: Kunnen inzien van de geldende regels op een te kiezen datum.
Kunnen ondersteunen van separate processen voor verschillende tegelijkertijd onderhanden wijzigingen in omgevingsdocumenten (visie, progamma, plan, voorbereidingsbesluit)
Toelichting:
Denk hierbij aan de volgende functionaliteiten:
Kunnen ondersteunen van separate processen voor verschillende tegelijkertijd onderhanden wijzigingen
Aangepast in versie 1.5: Nieuw requirement n.a.v. de functionele set
Onderstaande tabel toont alle requirements die gelden voor de Omgevingsbeleidcomponent met de categorie SHOULD. VNG hecht grote waarde aan het voldoen van de Omgevingsbeleidcomponent aan onderstaande requirements, maar deze requirements zijn niet verplicht tijdens de inwerkingtreding van de Omgevingswet. Als gemeente kunt u deze requirements uitvragen aan een leverancier als toevoeging op uw Programma van Eisen (PvE). Mogelijk dat een leverancier deze requirements nog niet heeft gerealiseerd in zijn oplossing.
Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB waardoor de specificaties van de release nog kunnen wijzigen tot de datum van inwerkingtreding.
Kunnen beschikbaar stellen van informatie over activiteiten (en gerelateerde informatie zoals locaties en regels) aan de toepasbare regelcomponent conform de specificaties van de API Regels bij activiteiten zoals gepubliceerd op https://github.com/VNG-Realisatie/Regels-bij-activiteiten.
Toelichting:
Aangepast in versie 1.4.1: Categorie aangepast van Onbepaald naar Should ivm standaardisatie API door VNG
Aangepaste requirement in versie 1.4: API verwijzing opgenomen
Aangepaste requirement in versie 1.3: scherper verwoord dat het om informatie-uitwisseling gaat
Tijdens het opstellen de tekst en geometrie valideren op zaken als: verplichte velden ingevuld, gesloten zijn van geometrie, eventuele verplichte annotaties etc.
Kunnen toepassen van (meta)gegevens tijdens het opstellen, wijzigen en annoteren van juridische regels van een omgevingsbeleiddocument
Het toepassen omvat het zoeken, het overnemen van de verwijzing, en visualiseren van de functionele structuur in relatie tot beoogde annotaties van juridische regels.
Toelichting:
Het gaat om de toepassing van verwijzingen naar concepten, juridische termen en objecten (waaronder waardenlijsten) in een omgevingsbeleidsdocument
De (meta)gegevens worden verkregen door het aanroepen van de DSO-LV Stelselcatalogus API 'Catalogus opvragen'
Aangepast in versie 1.5: Categorie van MUST naar SHOULD
Onderstaande tabel toont alle requirements die gelden voor de Omgevingsbeleidcomponent met de categorie ONBEPAALD. VNG onderkent een aantal requirements die op dit moment van toepassing kunnen zijn op de Omgevingsbeleidcomponent. VNG heeft hier echter geen waarde aan toegekend. Als gemeente kunt u eventueel deze requirements uitvragen aan een leverancier als toevoeging op uw Programma van Eisen (PvE). Bepaal dan wel vooraf de categorie die u hieraan zelf toekent: MUST of SHOULD. Mogelijk dat een leverancier deze requirements nog niet heeft gerealiseerd in zijn oplossing.
Kunnen annoteren van locatie met bijvoorbeeld bijbehorende juridische regels, waarden of activiteiten.
Toelichting:
Onder annoteren wordt verstaan het toevoegen van gegevens aan (onderdelen van) besluiten en regelingen, gegevens die die besluiten en regelingen machineleesbaar maken.
Annoteren is afgebakend tot de kenmerken genoemd in het Informatiemodel Officiële Publicaties (IMOP) en in het Informatiemodel Omgevingswet (IMOW).
Kunnen bieden van inzicht aan gebruikers van de delen van de regeling waaraan gewerkt wordt.
Toelichting:
Het betreft het vastleggen van de afspraken tussen organisaties over welke onderdelen van de regeling bij wie onderhanden zijn.
Aangepast in versie 1.4.1: Tekstuele aanpassing in toelichting van 1.4
Tekst aangepast in versie 1.4. Was: Kunnen ondersteunen van tegelijk werken aan plan binnen organisatie. Is geworden: Kunnen ondersteunen van tegelijk werken aan (lopende) regeling tussen organisaties.
Kunnen bevragen van de dataset behorende bij de regeling.
Kunnen doorzoeken, selecteren, c.q. automatisch presenteren van de informatie in het omgevingsplan op basis van wat relevant is voor het gebruik op dat moment.
Toelichting:
Kunnen tonen van een locatie in combinatie met een waarde
Kunnen tonen van alle juridische regels, die voldoen aan bepaalde (zoek)criteria, op een bepaalde locatie
Aangepast in versie 1.5: Toelichting aangepast
Aangepoast in versie 1.4.1: Typefouten uit toelichting verwijderd
Aangepast in versie 1.3: Tekst aangescherpt. Van categorie "could" naar categorie "onbepaald" waarmee de gemeente zelf het belang kan aangeven.
Kunnen vastleggen van de relatie tussen de regels in het omgevingsplan en tekst uit programma of visie.
Toelichting
Intern kunnen toetsen van de impact van de samenhang van de regels tussen deze onderdelen (visie, programma, plan, voorbereidingsbesluit).
Aangepast in versie 1.4.1: Typefouten uit toelichting verwijderd
Aangepast in versie 1.4: Was: Kunnen leggen van relatie tussen eigen omgevingsdocument en ander omgevingsdocument. Wordt: Kunnen leggen van relatie tussen regelingen.
Aangepast in versie 1.1: van could naar "categorie onbepaald" waarmee de gemeente zelf het belang kan aangeven.
Kunnen genereren van een regeling met wijzigingen, op een eerder gepubliceerde versie van die regeling, door bijvoorbeeld een stedenbouwkundig adviesbureau ten behoeve van organisaties die het maken van hun omgevingsplan uitbesteden.
Toelichting:
Het gegenereerde bestand is conform het uitwisselpakket zoals dat beschreven is op de website van KOOP.
Aangepast in versie 1.5: Exportformaat opgenomen in toelichting
Aangepast in versie 1.4.1: Typefoutren uit toelichting verwijderd
Nieuw requirement in versie 1.4, heeft betrekking op de zgn. plan-plan-keten.
De gebruikte gepubliceerde versie van die regeling is de geconsolideerde versie die op het moment van starten van het wijzigen opgehaald is uit de LVBB. Bij het aanbieden van de regeling met wijzigingen kan de geconsolideerde regeling in de LVBB inmiddels aangepast zijn.
Het kunnen ondersteunen van integraal/samenhangend werken voor het samenbrengen van diverse activiteiten en thema's in de lopende regeling binnen de eigen organisatie.
Toelichting:
Aangepaste toelichting in versie 1.4
Deze requirement heeft geen relatie met Zaakgericht werken.
Op deze bladzijde bieden we in tabelvorm en ter download de requirements (specificaties) aan voor de software voor toepasbare regels per 2024. Requirements geven inzicht in de wensen en eisen die we stellen aan software. De requirements zijn bedoeld voor gemeenten die zich oriënteren op nieuwe software voor toepasbare regels dan wel een aanbesteding gaan doen. Ze helpen de inhoudelijk specialisten (o.a. juristen, regelanalisten en vergunningverleners), medewerkers van ICT (functioneel beheerders en informatiemanagers) en specialisten van inkoop en aanbesteding om gezamenlijk een beeld te vormen van de aan te besteden software.
De requirements worden met input van gemeenten en softwareleveranciers iteratief opgesteld. De onderstaande versie betreft de 1.5 versie. Dit is een stabiele versie die een gemeente kan gebruiken bij het selecteren van software voor toepasbare regels. Gezien de ontwikkelingen binnen het Digitaal Stelsel Omgevingswet, weten we dat de eisen die we aan de software stellen nog worden aangepast. Denk hierbij aan de ontwikkeling van de standaard voor toepasbare regels STTR.
Per versie worden er releasenotes als ODS-bestand ter download beschikbaar gesteld, waarin de verschillen tussen de vorige versie en de nieuwe versie naast elkaar worden weergegeven. Lees vooraf het tabblad waarop de instructies staan.
Wil een gemeente starten met een aanbesteding, dan bieden deze requirements een goede basis voor die aanbesteding. Wil je meer weten over de verschillende manieren van aanbesteden en op welke wijze je de daarbij requirements gebruikt? VNG heeft een Handreiking Aanbesteden.
Naar verwachting zullen de meeste leveranciers aan de belangrijkste requirements gaan voldoen (zie ook onderstaande indeling in categorieën). Dit zorgt er voor dat je qua functionaliteit als gemeente niet snel een "foute" keuze kan maken. Toch zullen de leveranciers op onderdelen gaan verschillen. Om hier inzicht in te verkrijgen zullen op deze site en in de handreiking ook vragen verschijnen waarmee een gemeente die inzicht kan verkrijgen. Denk hierbij aan vragen als: op welke manier gaat de leverancier ondersteuning bieden aan het koppelen van juridische en toepasbare regels?
Met de requirements en de leveranciersvragen biedt VNG aan gemeenten een uniforme manier van uitvragen van de software voor toepasbare regels. Een uniforme manier van uitvragen is essentieel om komende periode van implementatie succesvol te laten verlopen. Softwareleveranciers staan al onder druk om in 2023 werkende software te kunnen leveren. Als iedere gemeente op haar eigen manier met eigen requirements de software gaat aanbesteden, levert dit voor de softwareleveranciers veel werk op. De tijd die ze daarmee besteden aan het meedoen met de aanbesteding, kunnen ze niet gebruiken om de software te ontwikkelen. Door op een als gemeenten op een uniforme wijze aan besteden, zorgen we er voor dat leveranciers kunnen focussen de ontwikkeling van software.
We hanteren de volgende categorieën voor de requirements, die meer in lijn liggen met de ‘Minimale acties Omgevingswet’. De requirements zijn onderverdeeld in drie categorieën:
Must. Deze functionaliteiten zijn noodzakelijk om de wet uit te kunnen voeren op het moment dat de wet in werking treedt. Het gaat om functionaliteiten om aan te kunnen sluiten op DSO-LV en andere verplichte landelijke voorzieningen en om functionaliteiten om essentiële processtappen uit te kunnen voeren. Functionaliteiten in deze categorie zijn in alle gevallen ‘Must Have’. Voorbeelden hiervan zijn, het kunnen produceren van een omgevingsplan in STOP-formaat en het kunnen publiceren van dit plan naar LVBB, het kunnen ophalen van een vergunningaanvraag in STAM-formaat en het kunnen verlenen van een omgevingsvergunning.
Should. Deze functionaliteiten zijn gezien vanuit het wettelijke minimum niet noodzakelijk om de wet uit te kunnen voeren, maar volgens VNG wel essentieel voor een adequate uitvoering. Deze functionaliteiten zijn volgens VNG minimaal ’Should Have’. U kunt besluiten om enkele van deze functionaliteiten als ‘Must Have’ te bestempelen als u ze voor uw eigen situatie noodzakelijk acht. Een voorbeeld van een functionaliteit in deze categorie is functionaliteit voor het aansluiten op de samenwerkingsfunctionaliteit van DSO-LV. Deze aansluiting is niet verplicht, maar wel essentieel om binnen de wettelijke termijn een vergunningaanvraag in samenwerking met andere partijen af te kunnen handelen.
Onbepaald. Deze functionaliteiten zijn niet noodzakelijk vanuit het wettelijke minimum of essentieel voor een adequate uitvoering. VNG kan daarom aan deze functionaliteiten geen belang toekennen. U dient zelf te bepalen hoe gewenst deze functionaliteiten voor situatie is. VNG raadt aan om deze softwarerequirements te internaliseren voordat u ze gebruikt bij het definiëren van een PvE voor uw software door uw lokale situatie te vertalen in ‘must haves’, ‘should haves’, ‘could haves’ en ‘won’t haves’.
Doorontwikkeling applicaties: Na de inwerkingtreding van de Omgevingswet zal de software voor toepasbare regels zich verder ontwikkelen. Gemeenten hebben hierbij aangegeven dat ze graag zien dat de software gaat voldoen aan Common Ground en dat de gehele beleidscyclus (van visie, naar plan, vergunning verlening, toezicht, handhaving en evaluatie) wordt ondersteund met integrale software.
De Toepasbare regelscomponent bevat applicatiefuncties die benodigd zijn voor het beheren en digitaal beschikbaar stellen van toepasbare regels op basis van de regels uit beleid. Denk hierbij aan een omgevingsvisie, programma of omgevingsplan.
Overzicht requirements per applicatiefunctie (uit model: Omgevingswet) - Toon SVG - Download als csv
De opgenomen requirements kunnen per applicatiefunctie als CSV bestand worden gedownload. Deze bestanden kunt u gebruiken bij het opstellen van een Programma van Eisen.
In onderstaande tabellen wordt onderscheid gemaakt in welke requirements verplicht zijn bij de inwerkingtreding (MUST), welk requirements door VNG worden geadviseerd (SHOULD) en welke requirements aanvullende functionaliteit bieden (ONBEPAALD).
Onderstaande tabel toont alle requirements die gelden voor de Toepasbare regelscomponent met de categorie MUST. De Toepasbare regelscomponent moet bij de inwerkingtreding van de Omgevingswet voldoen aan onderstaande requirements.
Het kunnen toepasbaar maken van de activiteiten in de functionele structuur in DSO-LV zodat toepasbare regels geregistreerd kunnen worden. Door het creëren en wijzigen van attributen van activiteiten in de functionele structuur en het toevoegen van regelbeheerobjecten. Aan die ‘regelbeheerobjecten’ kunnen vervolgens de toepasbare regels worden gehangen.
Het kunnen registreren, wijzigen en beëindigen van de toepasbare regels in de Registratie Toepasbare Regels van DSO-LV, middels Standaard Toepasbare Regels STTR.
Om toepasbare regels te kunnen registreren is een koppeling nodig tussen het lokale regelbeheersysteem en het digitaal stelsel op basis van de standaard Digikoppeling.
Het kunnen importeren van toepasbare regels in STTR-formaat. DSO-LV biedt de mogelijkheid om toepasbare regels als STTR-bestand te downloaden.
Wijzigingen:
27-11-2019: MoSCoW-indeling
4-12-2020: MoSCoW-indeling veranderd van Onbepaald naar Should omdat kunnen importeren nodig is om de toepasbare regels bij de bruidsschat te kunnen importeren en aanpassen.
08-04-2022: MoSCow-indeling aangepast van Should naar Must
Het kunnen beheren van de behandeldienstconfiguratie waarmee een bevoegd gezag een activiteit waarvoor zij verantwoordelijk is kan koppelen aan een behandeldienst.
Deze functionaliteit is wel noodzakelijk, maar hoeft niet per se onderdeel van toepasbare-regels-software te zijn.
14-7-2021: Verwijzing naar informatie over beheren behandeldienstconfiguratie aangepast
14-7-2020: Tekstopmaak aangepast
8-7-2020: Beschrijving van de status van de service van het DSO geactualiseerd. Toegevoegd dat deze functionaliteit wel nodig is, maar niet per se onderdeel van toepasbare-regels-software dient te zijn. MoSCoW-indeling gewijzigd in Must.
14-7-2021: MoSCoW-indeling gewijzigd in Must omdat de service beschikbaar is.
14-7-2021: Alinea dat deze functionaliteit nog in ontwikkeling is verwijderd
14-7-2021: Verwijzing naar informatie over het beheren van de omgevingsoverlegconfiguratie toegevoegd
14-7-2020: Tekstopmaak aangepast
8-7-2020: Beschrijving van de status van de service van het DSO geactualsieerd. Toegevoegd dat deze functionaliteit wel nodig is, maar niet per se onderdeel van toepasbare-regels-software dient te zijn.
Kunnen ophalen van werkzaamheden uit de landelijke voorziening.
Werkzaamheden zijn bedoeld voor de incidentele initiatiefnemers zodat zij ondersteund worden om de juiste activiteiten te vinden tijdens het checken. Werkzaamheden zijn gekoppeld aan de laagste activiteit. Een werkzaamheid kan een koppeling hebben met één of meerdere activiteiten, een activiteit kan een koppeling hebben met één of meerdere werkzaamheden.
Onderstaande tabel toont alle requirements die gelden voor de Toepasbare regelscomponent met de categorie SHOULD. VNG hecht grote waarde aan het voldoen van de Toepasbare regelscomponent aan onderstaande requirements, maar deze requirements zijn niet verplicht tijdens de inwerkingtreding van de Omgevingswet. Als gemeente kunt u deze requirements uitvragen aan een leverancier als toevoeging op uw Programma van Eisen (PvE). Mogelijk dat een leverancier deze requirements nog niet heeft gerealiseerd in zijn oplossing.
Het kunnen zoeken in toepasbare regels met als zoekingang minimaal tekst, bijvoorbeeld door in een zoekveld tekst in te voeren met als zoekresultaat de toepasbare regels die die tekst bevatten. Daarnaast het kunnen zoeken op de relatie naar juridische activiteit en werkingsgebied als deze relaties in de software beschikbaar zijn.
Andere mogelijke zoekcriteria zijn:
Begin en einddata van toepasbare regels
Of toepasbare regels wel of niet zijn geregistreerd in DSO-LV en wanneer
Het kunnen afspelen van toepasbare regels voor checken en voor aanvragen zonder gebruik te maken van het omgevingsloket van DSO-LV.
Gemeenten willen hun toepasbare regels kunnen bekijken en testen voordat ze deze registreren in DSO-LV. Dit maakt het mogelijk om de eigen toepasbare regels op te stellen, te beproeven en aan te passen zonder ze steeds eerst in DSO-LV te moeten registreren. Aandachtspunten bij het afspelen zijn of de toepasbare regels werken conform verwachtingen, of er geen overbodige vragen worden gesteld, of de helpteksten kloppen en of de toepasbare regels tot de juiste conclusies leiden.
Het kunnen verifiëren van een STTR-bestand met de verificatieservice van DSO-LV of andere verificatie-functionaliteit. De verificatie-functie controleert de regels in het bestand en laat weten of de regels aan de standaard voldoen. De bestanden worden bij het controleren niet opgeslagen in het Register toepasbare regels.
Het kunnen ophalen van regels bij activiteiten uit de omgevingsbeleidcomponent.
De omgevingsbeleidcomponent bevat de juridische regels en bijbehorende werkingsgebieden en activiteiten waarvoor toepasbare regels opgesteld of aangepast gaan worden. De toepasbare regelscomponent vraagt bij de omgevingswetbeleidcomponent gegevens op over (Omgevingswet-)activiteiten en/of (bijbehorende) juridische regels, regelteksten en locaties.
Onderstaande tabel toont alle requirements die gelden voor de Toepasbare regelscomponent met de categorie ONBEPAALD. VNG onderkent een aantal requirements die op dit moment van toepassing kunnen zijn op de Toepasbare regelscomponent . VNG heeft hier echter geen waarde aan toegekend. Als gemeente kunt u eventueel deze requirements uitvragen aan een leverancier als toevoeging op uw Programma van Eisen (PvE). Bepaal dan wel vooraf de categorie die u hieraan zelf toekent: MUST of SHOULD. Mogelijk dat een leverancier deze requirements nog niet heeft gerealiseerd in zijn oplossing.
Het kunnen analyseren van juridische regels als basis voor het opstellen en beheren van toepasbare regels, omdat toepasbare regels hun grondslag hebben in de juridische regels.
Analyseren houdt onder andere in het onderkennen van de juridische activiteiten in de regelgeving en het onderkennen welke criteria bepalen wanneer een initiatief toestemmingsvrij, vergunningsplichtig, meldingsplichtig of informatieplichtig is en wat de indieningsvereisten zijn.
Het analyseren van juridische regels kan ook zonder software worden gedaan.
N.B. Onder toepasbare regels verstaan we hier (conform IMTR 1.1.2):
Toepasbare regels zijn begrijpelijke regels die zijn opgesteld op grond van juridische regels (zoals omgevingswet, AMvB’s, omgevingsplannen, en verordeningen). Zij bestaan uit: bedrijfsregels (business logica), uitvoeringsregels, eventueel conversieregels (uitvraging en koppeling data aan bedrijfsregels) en interactieregels (presentatielogica). Zij resulteren in begrijpelijke vragenbomen aan de initiatiefnemer.
Het kunnen vastleggen van de relatie tussen toepasbare regels en de juridische regels waarop ze zijn gebaseerd.
Voor het beheren van toepasbare regels is het zinvol om de relatie met de juridische regels waar ze op gebaseerd zijn te kennen. Bij wijzigingen in de juridische regels is dan te zien welke toepasbare regels hier mogelijk door geraakt worden.
Deze requirement betreft het kunnen relateren van juridische en toepasbare regels bij het bevoegd gezag zelf (vandaar 'lokaal' in de titel), bijvoorbeeld als omgevingsplan en de bijbehorende toepasbare regels nog in bewerking zijn en het omgevingsplan nog niet bekend is gemaakt. De requirement betreft niet het relateren van toepasbare regels aan de activiteiten in DSO-LV. Dat laatste is noodzakelijk en behoort tot requirement TR03.
Het kunnen beheren van verschillende versies van toepasbare regels en van sets van bij elkaar horende toepasbare regels, zoals de bij dezelfde juridische activiteit horende toepasbare regels voor checken (conclusie) en voor aanvragen (indieningsvereisten). Door wijzigingen in juridische regels of verbeteringen van de toepasbare regels zelf kunnen verschillende versies van toepasbare regels ontstaan.
Voor beheer van versies is het nodig om te kunnen zien welke versies zijn geregistreerd in DSO-LV en wat de begin- en einddata van de verschillende versies zijn.
Bij gemeenten werken vaak meerdere personen aan de toepasbare regels, zowel van binnen als van buiten de eigen organisatie. Deze moeten gelijktijdig de toepasbare regels kunnen beheren.
Het met meerdere personen kunnen werken aan toepasbare regels vraagt o.a. om het kunnen in- en uitchecken van toepasbare regels in een repository en logging van wijzigingen.
Het kunnen toetsen van de formuleringen van toepasbare regels (de vragen) aan een schrijfwijzer.
Er is online een schrijfwijzer voor teksten voor toepasbare regels beschikbaar op https://iplo.nl/digitaal-stelsel/toepasbare-regels-maken-aanleveren/schrijfwijzer/. Het doel van deze schrijfwijzer is dat iedereen op dezelfde manier schrijft voor het Omgevingsloket en het Digitaal Stelsel Omgevingswet (DSO). Gebruikers kunnen de teksten daardoor beter begrijpen en de vragen gemakkelijker beantwoorden.
Wijzigingen:
14-7-2021: Verwijzing naar schrijfwijzer vervangen
Het (deels) geautomatiseerd af kunnen leiden van toepasbare regels uit juridische regels of een andere basis voor de juridische en toepasbare regels, bijvoorbeeld een doelenboom.
Het kunnen ontsluiten van toepasbare regels voor andere software anders dan via STTR, o.a. voor hergebruik van de gegevens, het beheren van relaties (bijvoorbeeld met juridische regels) en het kunnen migreren naar andere software.
Enkele mogelijke vormen zijn bestandsuitwisseling, databasetoegang en services.
Het kunnen presenteren van toepasbare regels, inclusief alle achterliggende gegevens, aan personen die geen gebruiker van de software zijn.
Het opstellen van goede toepasbare regels vraagt de betrokkenheid van verschillende deskundigen. Het moet mogelijk zijn de toepasbare regels te bespreken met en te laten reviewen door verschillende deskundigen die geen toegang hebben tot de software en ook niet getraind zijn in het gebruiken ervan.
Enkele mogelijke vormen zijn een document (PDF, Word e.d.) en een webportaal gericht op raadplegen en reviewen in plaats van opstellen en beheren.
Op deze pagina bieden we in tabelvorm en ter download de requirements (specificaties) aan voor de VTH-software per 2024. Requirements geven inzicht in de wensen en eisen die we stellen aan software. De requirements zijn bedoeld voor gemeenten die zich oriënteren op nieuwe software voor omgevingsbeleid dan wel een aanbesteding gaan doen. Ze helpen de inhoudelijk specialisten (o.a. juristen, regelanalisten en vergunningverleners), medewerkers van ICT (functioneel beheerders en informatiemanagers) en specialisten van inkoop en aanbesteding om gezamenlijk een beeld te vormen van de aan te besteden software.
De requirements worden met input van gemeenten en softwareleveranciers iteratief opgesteld. De onderstaande versie betreft de 1.5.1 versie. Dit is een stabiele versie die een gemeente kan gebruiken bij het selecteren van software voor VTH ondersteuning. Gezien de ontwikkelingen binnen het Digitaal Stelsel Omgevingswet, weten we dat de eisen die we aan de software stellen nog worden aangepast. Denk hierbij aan de doorontwikkeling van STAM, de Samenwerkfunctionaliteit en een verdere uitbouw van Toezicht & Handhaving. Deze onderwerpen zijn nog in beweging en gaan zorgen voor aanpassingen in de requirements. Ook de feedback die we krijgen van gemeenten en leveranciers leiden ertoe, dat de requirements steeds aangepast zullen worden.
Per versie worden er releasenotes als ODS-bestand ter download beschikbaar gesteld, waarin de verschillen tussen de vorige versie en de nieuwe versie naast elkaar worden weergegeven. Lees vooraf het tabblad waarop de instructies staan.
Wil een gemeente starten met een aanbesteding, dan bieden deze requirements een goede basis voor die aanbesteding. Wil je meer weten over de verschillende manieren van aanbesteden en op welke wijze je de daarbij requirements gebruikt? VNG heeft een Handreiking Aanbesteden.
Naar verwachting zullen de meeste leveranciers aan de belangrijkste requirements gaan voldoen (zie ook onderstaande indeling in categorieën). Dit zorgt er voor dat je qua functionaliteit als gemeente niet snel een "foute" keuze kan maken. Toch zullen de leveranciers op onderdelen gaan verschillen. Om hier inzicht in te verkrijgen zullen op deze site en in de handreiking ook vragen verschijnen waarmee een gemeente die inzicht kan verkrijgen. Denk hierbij aan vragen als: Op welke manier zal de leverancier de samenwerkingsfunctionaliteit van het Digitale Stelsel Omgevingswet gaan ondersteunen?
Met de requirements en de leveranciersvragen biedt VNG aan gemeenten een uniforme manier van uitvragen van de VTH-software. Een uniforme manier van uitvragen is essentieel om komende periode van implementatie succesvol te laten verlopen. Softwareleveranciers staan al onder druk om in 2023 werkende software te kunnen leveren. Als iedere gemeente op haar eigen manier met eigen requirements de software gaat aanbesteden, levert dit voor de softwareleveranciers veel werk op. De tijd die ze daarmee besteden aan het meedoen met de aanbesteding, kunnen ze niet gebruiken om de software te ontwikkelen. Door op een als gemeenten op een uniforme wijze aan besteden, zorgen we er voor dat leveranciers kunnen focussen de ontwikkeling van software.
We hanteren de volgende categorieën voor de requirements, die meer in lijn liggen met de ‘Minimale acties Omgevingswet’. De requirements zijn onderverdeeld in drie categorieën:
Must Have: Deze functionaliteiten zijn noodzakelijk om de wet uit te kunnen voeren op het moment dat de wet in werking treedt. Het gaat om functionaliteiten om aan te kunnen sluiten op DSO-LV en andere verplichte landelijke voorzieningen en om functionaliteiten om essentiële processtappen uit te kunnen voeren. Functionaliteiten in deze categorie zijn in alle gevallen ‘Must Have’. Voorbeelden hiervan zijn, het kunnen produceren van een omgevingsplan in STOP-formaat en het kunnen publiceren van dit plan naar LVBB, het kunnen ophalen van een vergunningaanvraag in STAM-formaat en het kunnen verlenen van een omgevingsvergunning.
Should Have: Deze functionaliteiten zijn gezien vanuit het wettelijke minimum niet noodzakelijk om de wet uit te kunnen voeren, maar volgens VNG wel essentieel voor een adequate uitvoering. Deze functionaliteiten zijn volgens VNG minimaal ’Should Have’. U kunt besluiten om enkele van deze functionaliteiten als ‘Must Have’ te bestempelen als u ze voor uw eigen situatie noodzakelijk acht. Een voorbeeld van een functionaliteit in deze categorie is functionaliteit voor het aansluiten op de samenwerkingsfunctionaliteit van DSO-LV. Deze aansluiting is niet verplicht, maar wel essentieel om binnen de wettelijke termijn een vergunningaanvraag in samenwerking met andere partijen af te kunnen handelen.
Onbepaald: Deze functionaliteiten zijn niet noodzakelijk vanuit het wettelijke minimum of essentieel voor een adequate uitvoering. VNG kan daarom aan deze functionaliteiten geen belang toekennen. U dient zelf te bepalen hoe gewenst deze functionaliteiten voor situatie is. VNG raadt aan om deze softwarerequirements te internaliseren voordat u ze gebruikt bij het definiëren van een PvE voor uw software door uw lokale situatie te vertalen in ‘must haves’, ‘should haves’, ‘could haves’ en ‘won’t haves’.
VNG raadt aan om deze softwarerequirements te internaliseren voordat u ze gebruikt bij het definiëren van een PvE voor uw software door uw lokale situatie te vertalen in ‘must haves’, ‘should haves’, ‘could haves’ en ‘won’t haves’. Ga na welke softwarerequirement voor u van toepassing is en ga na of de hier aangegeven categorie ook bij u van toepassing is.
Voor requirements waarvoor de specificaties vanuit DSO-LV nog niet beschikbaar zijn hanteren we de categorie "Nader te bepalen". Zodra de specificaties voldoende stabiel zijn zullen we de juiste categorie aangeven. Requirements die niet meer gelden, zijn uit de lijst weggehaald. In de Releasenotes die horen bij deze versie is terug te vinden welke requirements nieuw zijn, welke requirements zijn aangepast en welke requirements zijn vervallen.
Doorontwikkeling applicaties: Na de inwerkingtreding van de Omgevingswet zal de VTH-software zich verder ontwikkelen. Gemeenten hebben hierbij aangegeven dat ze graag zien dat de software gaat voldoen aan Common Ground en dat de gehele beleidscyclus (van visie, naar plan, vergunning verlening, toezicht, handhaving en evaluatie) wordt ondersteund met integrale software.
De VTH-component is de software die benodigd is voor de ondersteuning van de VTH-processen. De component bevat een aantal functies die de verschillende processen ondersteunen. De componenten er omheen hebben een relatie met de VTH-componenten. GEMMA kent de Vergunning- Toezicht- Handhavingcomponent Omgevingswet (oftewel VTH-component). Dit is een component voor alle VTH functionaliteit. Voor de Omgevingswet applicatiearchitectuur is deze component in meerdere applicatiefuncties gesplitst. Onderstaande afbeelding geeft een overzicht van de component met de applicatiefuncties.
In een vorige versie van de requirements was de VTH-component onderverdeeld in meerdere (aparte) applicatiecomponenten, met het idee dat elk component apart aanbesteed en geïmplementeerd zou kunnen worden. In de praktijk zijn leveranciers nog niet zo ver. Daarom is een insteek gekozen dat de huidige requirements iets zeggen over de verschillende functies die de VTH-component moet kunnen ondersteunen. Deze aanpak sluit beter aan als gemeenten nu een aanbesteding in de markt willen zetten. Het past bij hetgeen op dit moment door leveranciers geboden wordt.
De VTH-component bevat applicatiefuncties die benodigd zijn voor het ondersteunen van diverse soorten vergunningverlening, het ondersteunen op het toezicht houden en het ondersteunen van het handhaven.
Overzicht requirements per applicatiefunctie (uit model: Omgevingswet) - Toon SVG - Download als csv
De opgenomen requirements kunnen per applicatiefunctie als CSV bestand worden gedownload. Deze bestanden kunt u gebruiken bij het opstellen van een Programma van Eisen.
In onderstaande tabellen wordt onderscheid gemaakt in welke requirements verplicht zijn bij de inwerkingtreding (MUST), welke requirements door VNG worden geadviseerd (SHOULD) en welke requirements aanvullende functionaliteit bieden (ONBEPAALD).
Onderstaande tabel toont alle requirements die gelden voor de VTH-component met de categorie MUST. De VTH-component moet bij de inwerkingtreding van de Omgevingswet voldoen aan onderstaande requirements.
Indien het ingediende Verzoek leidt tot een samenwerking met een ketenpartner, moet het mogelijk zijn om vanuit de VTH-software of Zaaksysteem een samenwerking in de Samenwerkfunctionaliteit van het DSO-LV te kunnen starten. Naast het initiëren van een Samenwerking, moet het ook mogelijk zijn om Samenwerkingen te stoppen, te wijzigen als de samenstelling van de samenwerking verandert en te verwijderen als de documenten uit de samenwerking zijn gearchiveerd.
Adviesaanvragen worden bij een (keten)partner uitgezet in de vorm van een actieverzoek. De VTH software moet deze actieverzoeken in de Samenwerkfunctionaliteit kunnen uitzetten naar partners, maar ook kunnen ontvangen van partners.
De DSO-LV stuurt een notificatiebericht dat er een Verzoek klaar staat. Dit bericht moet automatisch kunnen worden ingelezen in het systeem op basis van de STandaard Aanvragen en Meldingen (STAM). Het Verzoek wordt ingediend ten behoeve van een Omgevingsoverleg (Vooroverleg), als start van het behandelproces (Initiëren), als aanvulling op een eerder ingediend Verzoek (Aanvullen), of dat het Verzoek wordt ingetrokken (Intrekken). Er zijn 7 soorten Type Verzoek onderkend in de Omgevingswet, veelal zijnde een vergunningsaanvraag of melding:
Nadat er een notificatiebericht is ontvangen, kan het Verzoek op basis van de standaard worden opgehaald uit het DSO-LV. Het Verzoek wordt ingediend ten behoeve van Vooroverleg (Omgevingsoverleg), als start van het behandelproces (Initiëren), als aanvulling op een eerder ingediend Verzoek (Aanvullen), of dat het Verzoek wordt ingetrokken (Intrekken). Er zijn 7 soorten Type Verzoek onderkend in de Omgevingswet, veelal zijnde een vergunningsaanvraag of melding:
Nadat er een notioficatiebericht is ontvangen, kunnen de bijlagen bij het Verzoek op basis van de standaard worden opgehaald uit het DSO-LV. De documenten worden vastgelegd in de Documentregistratiecomponent.
Documenten (adviezen/rapporten/etc) die ketenpartners nodig hebben, moeten gedeeld kunnen worden in de Samenwerking. De VTH software kan hiervoor documenten opslaan in de Samenwerkfunctionaliteit. De documenten die door ketenpartners gedeeld worden via de Samenwerkfunctionaliteit van het DSO-LV moeten door de VTH software opgehaald kunnen worden. Dit kan nodig zijn bij het verder opstellen van het advies of bij het compleet maken van het dossier als de zaak in afgehandeld. Indien documenten worden gedownload, worden deze opgeslagen in de Documentregistratiecomponent.
Indien het Verzoek niet bij het juiste Bevoegd Gezag is ingediend, moet het Verzoek onverwijld kunnen worden overgedragen aan een ander Bevoegd Gezag. Dit verloopt via het DSO-LV. Het koppelvlak die het DSO-LV hiervoor beschikbaar stelt, wordt daarbij gebruikt.
De relevante begrippen uit het Omgevingsplan zijn een belangrijke basis voor de behandeling van een VTH-zaak. Deze begrippen zijn opgenomen in de stelselcatalogus en moeten voor de behandeling van de VTH-zaak daaruit kunnen worden geraadpleegd. Ook bij de uitvoering van Toezicht en Handhaving is het gewenst om de juiste begrippen te kunnen hanteren. De stelselcatalogus bevat datasets (informatieproducten) die nodig zijn als naslag of toets bij het behandelen van vergunningen, meldingen en informatieplichten. Bijvoorbeeld sets over Bouw, Natuur, Erfgoed en Externe veiligheid.
Ten behoeve van het samenwerken aan aanvragen wordt de stelselcatalogus ook gebruikt voor het opzoeken van producten en diensten die organisaties aan elkaar leveren.
Toelichting:
Categorie aangepast in versie 1.4.1 van Onbepaald naar Must i.v.m. PDC
Toelichting aangepast in versie 1.4.1: Opzoeken producten en diensten t.b.v. het samenwerken aan behandelen.
Tekst aangepast in versie 1.4 en categorie aangepast van Should naar Onbepaald
De relevante begrippen uit het Omgevingsplan zijn een belangrijke basis voor de behandeling van een VTH-zaak. Deze begrippen zijn opgenomen in de stelselcatalogus en moeten voor de behandeling van de VTH-zaak daaruit kunnen worden geraadpleegd. Ook bij de uitvoering van Toezicht en Handhaving is het gewenst om de juiste begrippen te kunnen hanteren. De stelselcatalogus bevat datasets (informatieproducten) die nodig zijn als naslag of toets bij het behandelen van vergunningen, meldingen en informatieplichten. Bijvoorbeeld sets over Bouw, Natuur, Erfgoed en Externe veiligheid.
Ten behoeve van het samenwerken aan aanvragen wordt de stelselcatalogus ook gebruikt voor het opzoeken van producten en diensten die organisaties aan elkaar leveren.
Toelichting:
Categorie aangepast in versie 1.4.1 van Onbepaald naar Must i.v.m. PDC
Toelichting aangepast in versie 1.4.1: Opzoeken producten en diensten t.b.v. het samenwerken aan behandelen.
Tekst aangepast in versie 1.4 en categorie aangepast van Should naar Onbepaald
Conform art. 4.5 Awb stelt de gemeente een (redelijke) termijn voor het aanleveren van gegevens en bescheiden: de beslistermijn wordt opgeschort tot de dag waarop de aanvraag is aangevuld of de gestelde termijn daarvoor is verstreken.
In geval van instemming door andere bestuursorganen wordt de reguliere procedure verlengd met vier weken. Bij enkel advies door andere bestuursorganen geldt deze verlenging niet. Ook bij Handhaving moet het mogelijk zijn termijnen te kunnen verlengen.
Door de Samenwerkfunctionaliteit worden notificaties gestuurd naar partners als er in de Samenwerking iets is gewijzigd. Dit kan een uitnodiging voor een nieuwe samenwerking zijn, een actieverzoek of een nieuwe status van het uitgezette actieverzoek of een notificatie als er een document beschikbaar is gesteld in de Samenwerking.
In het Verzoek kunnen meerdere activiteten van hetzelfde type worden opgenomen. Het VTH-systeem moet deze verschillende activiteiten kunnen onderscheiden en kunnen verwerken.
De procesuitvoering - inclusief de daarbij ontvangen en gecreëerde informatieobjecten - zodanig met metadata kunnen vastleggen en vasthouden dat deze de voor duurzame toegankelijkheid noodzakelijke metadata bevatten en - na definitief worden - niet meer te wijzigen zijn (anders dan noodzakelijk vanwege duurzame toegankelijkheid).
Duurzame toegankelijkheid is het doel van werkzaamheden die veelal aangeduid worden met ‘archiveren’, ‘archiefbeheer’ e.d. We spreken hier van ‘duurzame toegankelijkheid’ omdat ‘archiveren’ vaak als iets achteraf, iets aparts gezien wordt terwijl duurzame toegankelijkheid al op elk moment tijdens de procesuitvoering speelt;
Bij het zaakgericht uitvoeren en - conform RGBZ - registreren van het proces voor het behandelen van ontvangen verzoeken, ontstaat 'als vanzelf' een RGBZ-conforme zaakregistratie en -dossier. De daarin vastgelegde metadata volstaan voor het kunnen borgen van duurzame toegankelijkheid mits voorzien wordt in daarvoor verplichte metadata;
Een term die veel voor 'informatieobject' gebruikt wordt is ‘document’. Maar niet elk informatieobject is in het spraakgebruik een document. Een voorbeeld daarvan is het verzoek dat als digitaal xml-bestand is ontvangen. Dit is één van de te borgen soorten informatie-objecten, maar of dit ook als document beschouwd wordt?
Let op: De gemeente is zelf verantwoordelijk voor het conform wettelijke normen borgen van de duurzame toegankelijkheid van adviezen van ketenpartners die via de Samenwerkingsfunctionaliteit beschikbaar worden gesteld. De Samenwerkingsfunctionaliteit vervult deze functie niet;
Het volledig en in continuïteit borgen van duurzame toegankelijkheid is geen verplichting voor deze component mits de ontbrekende ‘archieffuncties’ met andere applicaties ondersteund kunnen worden (migratie, vernietiging e.d.). Minimale vereiste is het kunnen vastleggen en ongewijzigd kunnen vasthouden van genoemde informatie.
De antwoorden bij de indieningsvereisten van de aanvrager geven al belangrijke informatie over vergunningplichten in relatie tot de voorgenomen activiteiten. Dit is elementaire informatie bij de intake van de aanvraag en de start van de behandeling.
Ontvangen aanvragen en genomen besluiten worden conform art. 16.63 Ow ten behoeve van belanghebbenden gepubliceerd in een of meer dag-, nieuws- of huis-aan-huisbladen of op een andere geschikte wijze, onder vermelding van de datum van ontvangst. Vanaf 1 juli 2021 moet conform de Wet elektronische publicaties dit gepubliceerd worden op https://www.officielebekendmakingen.nl. De publicatie verloopt via het DROP koppelvlak naar KOOP.
Het bevoegd gezag levert een kennisgeving inclusief bijlagen (dossier) aan via DROP. De kennisgeving wordt geleverd met een vlakcontour (geometrie conform GML in STOP/TP standaard, inclusief een unieke identificator die wordt uitgegeven door het bevoegd gezag) van het gebied waarvoor de afwijkvergunning is verleend en (indien van toepassing) een verwijzing naar het plan waarop de afwijking van toepassing is.
Als een aanvraag buiten het Omgevingsloket om, dus op papier, is ingediend, moet deze inclusief alle gegevens alsnog in de VTH-applicatie geregistreerd worden, zodat deze gegevens benut kunnen worden bij de verdere behandeling van de aanvraag. De VTH software beschikt hiervoor over een dergelijke registratiefunctie.
In de legesregeling zijn de berekeningsmethoden vastgelegd voor de activiteiten die binnen een aanvraag om omgevingsvergunning kunnen worden aangevraagd. Om de leges voor een specifieke aanvraag te kunnen berekenen, moet de regeling kunnen worden ingevoerd in de VTH-applicatie.
Aanvragen en besluiten moeten zowel analoog als digitaal ter inzage worden gelegd. In het VTH-systeem moeten de bijlages bij aanvraag en besluit aangemerkt kunnen worden als publiceerbaar en beschikbaar gesteld kunnen worden.
Een initiatiefnemer kan na het indienen van de initiele aanvraag via het loket nog aanvullingen op de aanvraag indienen. Reeds ingevulde gegevens kunnen daarbij aangepast zijn, documenten kunnen toegevoegd, aangepast of verwijderd zijn of er kunnen werkzaamheden aan toegevoegd of verwijderd zijn. De VTH software beschikt over de mogelijkheid om het verschil van de inhoud (bijvoorbeeld op veldniveau) tussen de ontvangen verzoeken met hetzelfde verzoeknummer te tonen. De ontvangen verzoeken met het hoogste volgnummer en het één na hoogste volgnummer worden daarvoor gebruikt.
Een initiatiefnemer kan na het indienen van de initiele aanvraag via het loket nieuwe of aangepaste bijlagen als aanvullingen op de aanvraag indienen. In het ontvangen aanvullende verzoek zijn verwijzigingen naar alle bijlagen opgenomen, ook de bijlagen die al bij het bevoegd gezag bekend zijn. De VTH software herkent welke bijlagen al zijn opgehaald, haalt alleen de nieuwe (of aangepaste) bijlagen op en geeft hier een melding van aan de gebruiker.
Als de ontvangende organisatie van het triggerbericht niet de uitvoerende instantie is, moet het VTH systeem de keuze bieden aan de medewerker om te beslissen hoe het verwerkt moet worden.
Voor de behandeling van een verzoek kan het relevant zijn om te weten welke verzoeken eerder zijn ingediend op dezelfde locatie. Ook kan het interessant zijn om te zien welke verzoeken mogelijk bij een andere bestuurslaag zijn ingediend in een bepaald gebied. Informatie over dergelijke verzoeken kan worden opgevraagd via de API van het verzoekenregister van DSO-LV. De VTH-software kan het landelijke verzoekenregister via de daarvoor beschikbaar gestelde API gebruiken om op basis van meegegeven zoekcriteria een overzicht te tonen van gerelateerde verzoeken.
Onderstaande tabel toont alle requirements die gelden voor de VTH-component met de categorie SHOULD. VNG hecht grote waarde aan het voldoen van de VTH-component aan onderstaande requirements, maar deze requirements zijn niet verplicht tijdens de inwerkingtreding van de Omgevingswet. Als gemeente kunt u deze requirements uitvragen aan een leverancier als toevoeging op uw Programma van Eisen (PvE). Mogelijk dat een leverancier deze requirements nog niet heeft gerealiseerd in zijn oplossing.
De fysieke leefomgeving verandert voordurend, als gevolg van vergunningvrije, meldingsplichtige en vergunningplichtige activiteiten. Dat moet voortdurend kunnen worden bijgehouden (monitoring) om cyclisch of dynamisch te analyseren of de veranderingen in de fysieke leefomgeving passend zijn binnen de kaders die in het omgevingsplan zijn vastgesteld (functies, omgevingswaarden, doelstellingen, etc).
Voor toezicht, handhaving en monitoring is het van belang dat een beschikking wordt geregistreerd inclusief belangrijke metadata. Hierbij wordt metadata opgeslagen zoals:
type beschikking (Vergunning, maatwerkvoorschriften, handhaving)
datum beschikking
geldigheid (bv bij tijdelijke omgevingsvergunning)
betrokken activiteiten.
De beschikking wordt als document vastgelegd in de Documentenregistratiecomponent.
Voor een goede audittrail moet correspondentie bij de zaak worden geregistreerd. De bijhorende documenten worden vastgelegd in de Documentenregistratiecomponent.
Toelichting:
In benaming van requirement '(inkomende)' verwijderd en tekst aangepast in versie 1.4
Een proces-verbaal, een advies, een verslag van een hoorzitting zijn voorbeelden van belangrijke documenten die goed moeten worden vastgelegd nadat de inhoud (zonodig in overleg met betrokkenen) is vastgesteld. Daarbij kan worden vastgelegd wie op welke moment de vaststelling heeft gedaan. De documenten worden vastgelegd in de Documentenregistratiecomponent.
Het zaaknummer bij een bevoegd gezag is een uniek nummer. Het DSO-LV Verzoeknummer is ook een uniek nummer dat de aanvrager vanuit het Omgevingsloket heeft ontvangen. Voor zowel aanvrager, bevoegd gezag en alle betrokkenen bij de behandeling is het daarom noodzakelijk dat er een relatie kan worden gelegd tussen het DSO-LV Verzoeknummer en het eigen interne zaaknummer (afkomstig van het Zaakregister), o.a. voor heldere communicatie en goede koppeling naar andere gerelateerde zaken.
Gegevens en bescheiden waarover de gemeente al beschikt, hoeven niet door de aanvrager te worden geleverd. De VTH software heeft koppelingen naar relevante (landelijke) basisregistraties om dergelijke gegevens te raadplegen.
Een ingediend Verzoek moet geheel of gedeeltelijk buiten behandeling gesteld kunnen worden. Dit kan voorkomen als er bijvoorbeeld voor het ingediende Verzoek geen vergunningsplicht is of als niet of in onvoldoende mate aan de gestelde aanvraagvereisten is voldaan. Dit betreft de status van de zaak zetten via de ZDS standaard in de Zaakregistratiecomponent of via de Zaken API in het Zaakregister.
Bij de inhoudelijke toetsing worden de activiteiten waarvoor de vergunning wordt aangevraagd door het bevoegd gezag vergeleken met de kaders van de geldende regelgeving. Daartoe wordt op alle relevante deelgebieden van de regelgeving getoetst of het initiatief binnen de kaders blijft. De resultaten van de toetsing kunnen in een risicogericht toetsingsprotocol worden vastgelegd.
Een risicoprofiel van de aanvraag (en de daarin aangevraagde activiteiten), op basis waarvan een bijbehorende toetsings- en toezichtsprotocol van toepassing is waarin de diepgang overeenkomst met het vastgelegde risicoprofiel.
Een zaak moet kunnen worden toegewezen aan een specifieke medewerker als hoofdbehandelaar, zodat de zaak in zijn/haar werkvoorraad wordt opgenomen en hij/zij de juiste rechten krijgt om de zaak te afhandelen. Hetzelfde geldt voor behandelaren en adviseurs die worden gevraagd om specifieke aspecten van de aanvraag te toetsen of daarop te adviseren.
De hoofdbehandelaar van een zaak moet goed overzicht hebben over voortgang van de zaak. Daar hoort bij dat de hoofdbehandelaar kan zien wat de voortgang is bij gevraagde adviezen (intern en extern) om op tijd te kunnen zien of er een knelpunt in de planning van een zaak. Het totaaloverzicht van de eindstatussen van de adviesvragen geeft een beeld op hoofdlijnen of er inhoudelijke knelpunten zijn en daarop moet worden geschakeld.
Voor de monitoring van de bedrijfsvoering, zowel organisatiebreed als op individueel niveau, moeten de statussen van de (lopende) zaken kunnen worden bijgehouden. Klant(en) hebben ook behoefte aan inzicht in de voortgang van de eigen zaak. Afhankelijk van het type zaak, kan het daarbij gaan om een aanvrager, overtreder en/of belanghebbende.
Aangezien de inhoudelijke toetsing belegd kan zijn bij diverse interne en externe adviseurs en ketenpartners, is bewaken van de termijnen voor levering van de adviezen en/of instemmingen noodzakelijk.
Voor het automatisch kunnen aanmaken en updaten van zaken, is een koppeling naar een Zaaksysteem nodig. Deze standaard wordt gebruikt als een organisatie nog een Zaaksysteem gebruikt dat alleen de Zaak- en Documentenservices standaard gebruikt. Deze koppeling is gebaseerd op de verouderde standaard en voldoet minimaal aan de versie(s) zoals deze wordt beheerd door VNG Realisatie.
De nieuwe standaard Zaakgericht Werken API volgt de landelijke URI en API strategie. Deze nieuwe standaard is gebaseerd op REST/JSON en wordt ingezet om geautomatiseerd Zaakgericht te kunnen werken met infromatiesystemen van gemeenten of uitvoeringorganisaties. Minimaal de versie(s) zoals deze wordt beheerd door VNG Realisatie wordt hiervoor gebruikt. De Zaakgericht Werken standaard is de nieuwe standaard die per 1 april 2021 op de Pas-Toe-Of-Leg-Uit-lijst van de VNG staat.
De uitkomst van een zaak kan de aanleiding zijn om een andere zaak te starten. Bijvoorbeeld: de behandeling van een melding van een incident kan als uitkomst hebben dat handhavend moet worden opgetreden. Daarvoor moet dan een zaak worden gestart voor het opleggen van een sanctie. Deze zaken moeten aan elkaar worden gerelateerd, zodat in de nieuwe zaak de voorgeschiedenis en relevante informatie direct inzichtelijk is.
Verschillende zaken kunnen met elkaar samenhangen en dat moet voor een hoofdbehandelaar in één oogopslag duidelijk zijn, inclusief de actuele status. Bijvoorbeeld: een melding incident leidt tot het opleggen van een sanctie, waarbij toezicht wordt gehouden en uiteindelijk een sanctie wordt toegepast. Dan zijn er vier zaken aan elkaar gerelateerd. Of er worden voor éen bouwproject meldingen en informatieplichten door verschillende personen ingediend met verschillende verzoeknummers, dan moeten deze verschillende verzoeken/zaken aan elkaar gerelateerd kunnen worden.
Voor samenwerking in de keten is de randvoorwaarde dat met een uniforme werkwijze zaakgericht wordt gewerkt op basis van de interbestuurlijke ZTC-Omgevingswet, zodat de VTH-componenten het berichtenverkeer op de juiste en uniforme manier verwerken. De VTH-component maakt gebruik van de ZTC-Omgevingswet. Samenwerken gebeurt op basis van leveren van producten. Dat wordt voorlopig in een apart PDF vastgelegd. Bij de aanroepen van een actieverzoek via de SW-API wordt een productcode van het gevraagde product meegegeven.
Als het Verzoek volledig is afgehandeld, kan het Bevoegd Gezag de werkmap verwijderen in de DSO-LV. Dit verwijderen staat los van het verzoek in mijn omgevingsloket van de indiener. Die staat nog in de zogenoemde Projectmap.
De VTH software kan een zaak registreren via de Zaak- en Documenten standaard (gebaseerd op StUF) in de Zaakregistratiecomponent, de afhandeling (uitvoering en bewaking van het proces) gebeurt vervolgens in de VTH software. Daarom moeten de gegevens kunnen worden uitgewisseld tussen deze componenten. Deze standaard wordt gebruikt als een organisatie nog een Zaaksysteem gebruikt dat alleen de Zaak- en Documentenservices standaard gebruikt.
De VTH software kan een zaak registreren via de Zaakgericht Werken standaard (gebaseerd op RESTful API) in de Zaakregistratiecomponent, de afhandeling (uitvoering en bewaking van het proces) gebeurt vervolgens in de VTH software. Daarom moeten de gegevens kunnen worden uitgewisseld tussen deze componenten. De Zaakgericht Werken standaard is de nieuwe standaard die per 1 april 2021 op de Pas-Toe-Of-Leg-Uit-lijst van de VNG staat.
Bij het registreren van de zaak worden alleen zaaktypes gebruikt uit de zaaktypecatalogus. De Zaakgericht Werken standaard is de nieuwe standaard die per 1 april 2021 op de Pas-Toe-Of-Leg-Uit-lijst van de VNG staat.
Eerdere besluitvorming vormt een belangrijk kader voor een actuele VTH-zaak. Wanneer bijvoorbeeld een ontheffing voor een bepaalde, afwijkende activiteit eerder is geweigerd, kan dat daarna niet zomaar alsnog worden toegestaan. De Zaakgericht Werken standaard is de nieuwe standaard die per 1 april 2021 op de Pas-Toe-Of-Leg-Uit-lijst van de VNG staat.
Documenten worden in de Documentregistratiecomponent opgeslagen en niet in de VTH software. Bijhorende metadata worden in de Documentregistratiecomponent via de Zaak- en Documentenservices standaard opgeslagen en kunnen door het VTH-systeem worden bevraagd. De Zaak- en Document Services is de verouderde maar nog geldende standaard. Deze standaard wordt gebruikt als een organisatie nog een Zaaksysteem gebruikt dat alleen de Zaak- en Documentenservices standaard gebruikt.
Documenten worden in de Documentenregister opgeslagen en niet in de VTH software. Bijhorende metadata worden in het Documentenregister via de Documenten API opgeslagen en kunnen door het VTH-systeem worden bevraagd. De Zaakgericht Werken standaard is de nieuwe standaard die per 1 april 2021 op de Pas-Toe-Of-Leg-Uit-lijst van de VNG staat.
Als de behandeling van de vergunningaanvraag is overgedragen aan een ander bestuursorgaan, als de aanvrager de aanvraag heeft ingetrokken of wanneer de vergunningaanvraag buiten behandeling is gesteld omdat er geen vergunningplicht is of omdat niet in voldoende mate aan de aanvraagvereisten is voldaan, eindigt het bedrijfsproces na de intakefase en wordt de aanvraag afgerond.
Na vaststelling door het bevoegde orgaan (met verwerking van eventuele aanpassingen), wordt het document dat formeel is vastgesteld 'bevroren', waarmee een behandelingsfase is afgerond. Het kan hierbij gaan om - Ontwerp beschikking omgevingsvergunning (college) - Ontwerp advies met instemming (raad) - Definitieve beschikking omgevingsvergunning (college of gemandateerde ambtenaar) - Definitief Advies met instemming (raad) In feite betreft het hier het afronden van een processtap. Dit kan mogelijk leiden tot het aanpassen van een status van de zaak.
Onderstaande tabel toont alle requirements die gelden voor de VTH-component met de categorie ONBEPAALD. VNG onderkent een aantal requirements die op dit moment van toepassing kunnen zijn op de VTH-component. VNG heeft hier echter geen waarde aan toegekend. Als gemeente kunt u eventueel deze requirements uitvragen aan een leverancier als toevoeging op uw Programma van Eisen (PvE). Bepaal dan wel vooraf de categorie die u hieraan zelf toekent: MUST of SHOULD. Mogelijk dat een leverancier deze requirements nog niet heeft gerealiseerd in zijn oplossing.
Het is noodzakelijk om in een toezichts- of handhavingszaak het naleefgedrag te kunnen registreren en te kunnen koppelen aan de thema's die zijn gecontroleerd om periodiek een goede risicoanalyse uit te kunnen voeren.
Inhoudelijk deskundige interne en/of externe adviseurs brengen een advies uit, waarin behalve de conclusie of het past ook kan worden opgenomen welke aanpassingen aan het initiatief gedaan zouden kunnen worden om het passend te maken. Het betreft hier tekstuele vastlegging in het systeem en niet de eventueel bijhorende documenten, zoals het vastleggen/registreren van advies voor vervolg in relatie tot handhavingsbeleid, bijvoorbeeld: Overtreding J/N, Ernst overtreding, Gedrag overtreder of Advies sanctie.
Bij de behandeling van VTH-zaken kunnen gegevens/documenten uit gerelateerde zaken uit het verleden van belang zijn of zelfs het uitgangspunt voor de behandeling van de zaak. De VTH software haalt deze gegevens of documenten bijvoorbeeld uit een Archiefregistratiecomponent.
VTH-besluiten hebben gevolgen voor de fysieke leefomgeving en brengen risico's in relatie tot het naleefgedrag in beeld. Het is daarmee belangrijke informatie voor monitoring en analyse.
Op verschillende momenten binnen diverse processen moeten brieven of besluiten kunnen worden opgesteld voor een indiener of belanghebbende. De VTH software kan documenten aanmaken aan de hand van vooraf gedefinieerde sjablonen in de huistijl van de organisatie. Mogelijk dat hiervoor de Documentcreatiecomponent wordt gebruikt, indien de organisatie hierover beschikt.
De initiatiefnemer en eventuele specifieke belanghebbenden krijgen de stukken toegezonden of worden uitgenodigd tot indienen van zienswijzen (bv. informatieve of inhoudelijke brieven). Dit kan bijvoorbeeld via e-mail of brief.
Bij complexe en/of beleidsgevoelige vergunningaanvragen accordeert het College de conceptbeschikking. Tevens wordt bepaald of advies aan de Gemeenteraad gevraagd zal worden. Het daadwerkelijk accorderen wordt buiten het VTH-systeem gedaan. In feite betreft het hier het starten en volgen van een processtap.
Bij eenvoudige vergunningaanvragen wordt op ambtelijk niveau besloten. Uit oogpunt van zorgvuldigheid is het belangrijk de beschikking inclusief legesberekening c.q. -beschikking in elk geval door een tweede persoon (een collega of teamleider) te laten toetsen.
Op basis van de uitkomst van de integrale afweging wordt via de Documentcreatiecomponent een concept voor de beschikking opgesteld (bij toepassing van de uitgebreide procedure spreken we van 'ontwerpbeschikking'). Hierin worden eventuele maatwerkvoorschriften opgenomen die de gemeente wil verbinden aan het verlenen van de vergunning.
Op grond van de geldende legestarieven moet de aanvrager van een omgevingsvergunning leges betalen voor de behandeling van de aanvraag. Het opleggen van de leges is een op zichzelf staande beschikking waartegen bezwaar kan worden gemaakt. Mogelijk dat hiervoor de Documentcreatiecomponent wordt gebruikt, indien de organisatie hierover beschikt.
Als een toezichthouder een overtreding constateert, moet de toezichthouder in tekst en beeldmateriaal vastleggen en ondertekenen wat hij/zij heeft gezien, heeft besproken en met wie (overtreder, getuigen, belanghebbenden, etc). Hieruit kan een formeel document - het proces-verbaal - worden gegenereerd.
Uitgangspunt in de Omgevingswet is dat zowel voor binnenplanse als buitenplanse activiteiten de reguliere procedure wordt gevolgd, tenzij sprake is van een bijzondere situatie. Van zo'n bijzondere situatie kan sprake zijn op grond van internationaalrechtelijke verplichtingen (bijvoorbeeld de MER-richtlijn of de Seveso-richtlijn), of als de aangevraagde activiteiten belangrijke nadelige gevolgen kunnen hebben voor het milieu, of als er sprake is van een rijksmonumentenactiviteit.
Op grond van de vastgestelde legestarieven (berekeningsmethode) worden met behulp van specificaties binnen de aanvraag (activiteiten, specifieke variabelen als bouwsom, vloeroppervlak) de verschuldigde leges berekend voor de behandeling van een specifieke aanvraag.
Vanuit de Kwaliteitscriteria is de landelijk handhavingstrategie als handreiking vastgesteld voor landelijke eenduidigheid in de uitvoering van toezicht en handhaving. Om de juiste sancties op te leggen en om de big-8-cyclus goed sluitend te maken, is het noodzakelijk dat de overtreding met de juiste categorie kan worden geregistreerd. Deze registratie wordt later door de data-analyse en monitoringcomponent gebruikt bij het monitoren en analiseren wat bij de uitvoering van toezicht (en handhaving) inhoudelijk wordt geconstateerd inclusief ernst en gedrag.
De indieningsvereisten voor aanvragen zijn gedeeltelijk landelijk en gedeeltelijk lokaal vastgesteld. Als (essentiële) vereisten ontbreken, kan de aan vraag niet goed worden beoordeeld en kan er geen goed afwegen besluit worden genomen op de aanvraag. Aanvragen die niet voldoen, kunnen daarom buiten behandeling worden gesteld.
Bij meervoudige/complexe zaken (VTH) zullen verschillende behandelaren en adviseurs input leveren. De hoofdbehandelaar moet ondersteund kunnen worden om het overzicht te behouden bij de intergrale afweging, overwegingen en uiteindelijke resultaat van de integrale afweging. Bijvoorbeeld door vanuit de deeltoetsingen (op hoofdlijnen) direct inzichtelijk te krijgen welke knelpunten er zijn en wat passend is (en dus geen issue is). Dit kan dan direct de agenda voor de integrale afweging zijn.
Inhoudelijk deskundige interne en/of externe adviseurs brengen een advies uit, waarin behalve de conclusie of het past ook kan worden opgenomen welke aanpassingen aan het initiatief gedaan zouden kunnen worden om het passend te maken. Ten behoeve van de integrale afweging moet kunnen worden aangegeven welke knelpunten er zijn en wat passend is (en dus geen issue is). Dit vormt dan gelijk de input voor de agenda van een gezamenlijke, integrale afweging.
Afhankelijk van het aantal en de omvang van de zienswijzen en de complexiteit van de verwerking daarvan kan de beantwoording van de zienswijzen opgenomen worden in het definitieve besluit of in een separate nota van beantwoording zienswijzen. De oplossingen die tijdens de integrale afweging gevonden zijn voor de eventuele geschilpunten uit de ingediende zienswijzen worden verwerkt in de beschikking en daaruit wordt het definitieve besluit voor de aanvraag omgevingsvergunning opgesteld. Tevens mogelijkheid om concreet aan te geven welke motivering in de tekst van de beschikking moet worden opgenomen en welke voorschriften (indien van toepassing).
Een behandelaar toetst een activiteit binnen de VTH-zaak en moet de toetsing met het resultaat kunnen vastleggen in een document. Het opstellen gebeurt via de Documentcreatiecomponent.
Op basis van het uitvoeringsbeleid bepaalt het bevoegd gezag in welke volgorde toezicht wordt gehouden. De prioritering kan gebeuren op basis van inspecties op thema's, onderwerpen en prioriteit.
Een bevoegd gezag bepaalt op basis van de prioriteiten in het uitvoeringsbeleid welke overtredingen wel of niet worden opgepakt of in welke volgorde deze worden opgepakt. Bij de afweging biedt de VTH software de mogelijkheid om bij de vastleggen te motiveren waarom overtreding niet, eerder of later wordt opgepakt.
De verschillende activiteiten worden (als deelzaken) in beginsel op zichzelf beoordeeld, waarna vervolgens integrale afweging plaatsvindt. Uiteindelijk moet het geheel leiden tot één integraal besluit, waarbij motiveringen van de verschillende activiteiten moeten worden samengevoegd en de integrale afweging wordt toegevoegd.
In sommige zaken is (positieve) besluitvorming randvoorwaardelijk om verder te kunnen gaan of om de zaak af te kunnen ronden. Een voorbeeld: Een handhavingszaak kan worden afgerond als de overtreding is opgeheven doordat de benodigde omgevingsvergunning is verleend.
Voor de beheersing van de werkvoorraad, zowel op het niveau van een individuele medewerker als (een onderdeel van) de organisatie, moeten rapportages kunnen worden gegenereerd.
Om actief te kunnen sturen, ondersteunt de VTH software het kunnen genereren van rapportages ten behoeve van het Management. Verder moeten rapportages kunnen worden gegenereerd voor monitoring van de resultaten van de uitvoering als belangrijke informatie voor het opstellen van beleid en regelgeving. De VTH software biedt hiervoor een aantal voorgedefinieerde rapportages (op basis van best practice).
Bij de verschillende bevoegde gezagen zullen verschillende speerpunten of aandachtspunten zijn vastgesteld voor de dienstverlening. Daarvoor moeten specifieke rapportages kunnen worden opgesteld.
De Gemeenteraad heeft bij afwijkingen van het omgevingsplan adviesrecht maar geen instemmingsrecht. Bovendien geldt dat een adviesvraag aan de Gemeenteraad geen reden is voor verlenging van de proceduredoorlooptijd. Het is daarom zaak om de eventuele adviesaanvraag bij de Gemeenteraad vroegtijdig te agenderen en zoveel mogelijk parallel uit te voeren met de verdere activiteiten in het proces. De Gemeenteraad ontvangt de adviesaanvraag van het College en agendeert deze.
Om het team dat de vergunningaanvraag behandelt tijdig te kunnen voorzien van gevraagde adviezen is het belangrijk om werkzaamheden aan de juiste medewerker(s) toe te wijzen en in te plannen in overleg met de hoofdbehandelaar. Het Verzoek moet kunnen worden toegekend aan een (hoofd)behandelaar. Deze is verantwoordelijk voor de verdere afhandeling van het Verzoek.
Afhandeling van zaken volgt lang niet altijd de 'happy flow' c.q. is lang niet altijd en lineair proces. Soms moeten delen van het proces worden herhaald/opnieuw. Uitgangspunt is dat de hoofdbehandelaar deskundig is, goed kan bepalen hoe het proces verder moet en daarbij dus flexibel keuzes kan maken. Processen moeten dus slim modulair kunnen worden geïmplementeerd.
Naast de wettelijke termijn, hanteren veel bevoegde gezagen servicetermijnen die korter zijn. Deze moeten kunnen worden ingesteld en vervolgens moet per proces de doorlooptijd worden bijgehouden en behoeve van rapportages.
Inhoudelijk deskundige adviseurs kunnen vanuit de VTH software gevraagd worden om advies uit te brengen in een VTH-zaak. De VTH software biedt hiervoor bijvoorbeeld de mogelijkheid tot het versturen van een interne e-mail of gebruikt hiervoor een ander notificatiemechanisme.
Om te voorkomen dat er meerdere aanvragen of meldingen op hetzelfde object worden ingevoerd, is inzage op eerdere ingediende of lopende zaken een hulpmiddel bij het beoordelen of de melding of aanvraag in behandeling moet worden genomen.
Indien sprake is van een omgevingsvergunning voor een afwijkactiviteit waaraan geen termijn is verbonden, dan moet binnen uiterlijk vijf jaar het omgevingsplan van de gemeente bijgewerkt worden zodat het met de verleende omgevingsvergunning in overeenstemming is. Dit zou als een aparte of gerelateerde Zaak gestart kunnen worden.
Dit is nodig voor starten van BAG proces, verkrijgen brondocument (vergunning, bouwtekeningen, etc.) voor de BAG, melding dat er een vergunning is verleend (gereedmelding), etc. Idealiter verloopt deze notificatie via de Notificatierouteringcomponent.
Bijvoorbeeld voor het factureren van opgelegde leges, verbeurd verklaarde dwangsommen of uitvoeringskosten moeten de relevante gegevens kunnen worden uitgewisseld met de financiële component.
Wanneer op basis van de toetsingsadviezen een planschaderisico geconstateerd wordt en er is geen onderliggend plan of overeenkomst, is het afsluiten van een planschadeovereenkomst met de initiatiefnemer wenselijk. Bij de inhoudelijke toetsing wordt ook onderzocht in hoeverre er planschaderisico bestaat. Mogelijk dat hiervoor een deelzaak wordt gestart.
Voor de Omgevingswet dient de gemeente op een aantal koppelvlakken aan te sluiten. Ieder koppelvlak maakt gebruik van een standaard. Onderstaande tekst geeft een overzicht van alle koppelvlakken en de bijbehorende standaard. Informatie is gebaseerd op het DSO-LV document Aansluitkoppelvlakken Editie Bevoegd Gezag. Het eerstgenoemde koppelvlak (Aansluiten DSO Toepasbare regels) dient een gemeente te gebruiken op het moment dat besloten wordt toepasbare regels aan te leveren aan de DSO-LV. Dit is geen wettelijk verplicht koppelvlak. De daaropvolgende zes koppelvlakken dient (wel wettelijke verplichting) een gemeente per 2024 in ieder geval in gebruik te hebben. Voor meer informatie over de de specifieke koppelvlakken (API's) verwijzen we naar het Omgevingswet API register.
Aansluiten DSO-LV Indienen aanvragen en meldingen[bewerken]
Het ketenproces Indienen Aanvragen en Meldingen levert de door de Initiatiefnemer ingevulde en ingediende vergunningsaanvraag of melding af bij het Bevoegd gezag. Er wordt een keuze gemaakt voor één bevoegd gezag die de aanvraag/melding krijgt aangeleverd.
Interoperabiliteit:
IMAM - DSO Informatiemodel Aanvragen Meldingen
STAM - DSO Standaard Aanvragen Meldingen
HAL (Hypertext Application Language)
Aansluiten Landelijke Voorziening Beschikbaar stellen en Bekendmaken[bewerken]
Het publiceren van Omgevingsdocumenten gebeurt op het platform voor Overheidspublicaties de Landelijke Voorziening Beschikbaar stellen en Bekendmaken (LVBB).
DROP staat voor Decentrale Regelgeving en Officiële Publicaties. Met DROP wordt het publicatieproces geïntegreerd met het consolidatieproces. Gebruikt voor het publiceren en consolideren van regelingen en kennisgevingen (bijvoorbeeld vergunningen).
Via Mijn Overheid Berichtenbox (burgers en bedrijven) kan de gemeente berichten versturen naar inwoners en bedrijven. Mijn Overheid Lopende Zaken wordt gebruikt voor het versturen van statusinformatie.
Informatieproducten worden via services aan het DSO-LV ter beschikking gesteld. Afname geschiedt via direct gebruik in DSO-LV Gebruikerstoepassingen (GT) of via het Open Stelsel. De standaard voor informatieproducten dient nog te worden vastgesteld.
In de vorige hoofdstukken hebben we de componenten, requirements en standaarden beschreven. Hier besteden we aandacht aan de koppelingen tussen de applicatiecomponenten, zowel binnen de gemeente als tussen gemeente en DSO-LV dan wel een andere landelijke voorziening. We doen dit in twee stappen:
Informatie uitwisseling tussen componenten geeft een overzicht van de informatiestromen tussen de belangrijkste componenten.
Interactiepatronen tussen componenten brengt per patroon inzichtelijk welke afhankelijkheden er tussen de componenten zijn waarbij wordt aangegeven welke requirement bij dat interactiepatroon geldt.
Informatie uitwisseling tussen componenten[bewerken]
Onderstaand figuur geeft een overzicht van de belangrijkste referentiecomponenten en informatiestromen tussen de componenten voor het IWT niveau weer. De opgenomen requirements van de verschillende omgevingswetcomponenten liggen hieronder ten grondslag. Dit betreft requirements met zowel de categorie Must, Should en Onbepaald.
Onderstaande diagrammen geven aan welke componenten, functies en requirements gebruikt worden in de communicatie tussen het DSO-LV, de gemeente en eventueel partners. De patronen zijn gebaseerd op de basisplaat Indringend Keten Testen welke gebruikt wordt door het programma Aan de Slag Met De Omgevingswet.
Gemeenten kunnen ten behoeve van een initiële lading de volledige geconsolideerde regeling ophalen en inladen in de omgevingsbeleidcomponent. De omgevingsbeleidcomponent gebruikt hiervoor de Downloaden API en ontvangt een ZIP-bestand met daarin de juridische tekst (het “OP-deel"), de Geografische Informatie Objecten (“GIO’s”) en de gegevens bij de juridische tekst (de “OW-objecten”). Dit interactiepatroon kan door de gemeente in de volgende gevallen worden toegepast:
Ten einde uitvalsituaties te voorkomen
Als 'back-up' bij wijziging van softwareleverancier
Partners (bijvoorbeeld stedenbouwkundige bureaus) kunnen ten behoeve van een initiële lading de volledige geconsolideerde regeling ophalen en inladen in de omgevingsbeleidcomponent. De omgevingsbeleidcomponent gebruikt hiervoor de Downloaden API en ontvangt een ZIP-bestand met daarin de juridische tekst (het “OP-deel"), de Geografische Informatie Objecten (“GIO’s”) en de gegevens bij de juridische tekst (de “OW-objecten”). Dit interactiepatroon wordt bijvoorbeeld gebruikt als een gemeente het wijzigen van een omgevingsplan heeft uitbesteed aan een stedenbouwkundig bureau.
Ten behoeve van het valideren van een omgevingsplan, levert de gemeente ter validatie een STOP-bestand aan het Bronhouderskoppelvlak aan. Het Bronhouderskoppelvlak levert een validatierapport op aan de gemeente met het resultaat van de validatie.
Stedenbouwkundige bureaus bieden gewijzigde onderdelen van de regelingversie ter validatie aan de DSO Landelijke voorziening. Het Plan-plan validatieportaal valideert de inhoud en biedt een validatierapport. De bedoeling is dat het portaal op den duur wordt uitgefaseerd en dat er een volwaardige API beschikbaar komt via het Open stelsel voor derden.
Ten behoeve van het publiceren van een omgevingsbesluit levert de gemeente het besluit in de vorm van een STOP-bestand aan het Bronhouderskoppelvlak aan. Het Bronhouderskoppelvlak levert een publicatie- en een validatierapport op aan de gemeente met het resultaat van de publicatie en de validatie. Als de verificatie geen fouten heeft opgeleverd wordt het bestand verwerkt tot een nieuwe versie van de geconsolideerde regeling.
De door het stedenbouwkundig bureau opgestelde nieuwe regelingversie (die eerst gevalideerd is, zie interactiepatroon 4) wordt aangeboden aan de omgevingsbeleidscomponent van de gemeente.
Het Team omgevingsbeleid kan met de treeviewer in de functionele structuur opzoeken of er toepasbare regels (vergunningchecker en aanvraagformulier) aanwezig zijn bij de juridische activiteit. Dit is handig om te zien of er toepasbare regels in de bruidsschat of bij andere gemeentes zijn die als uitgangspunt gebruikt kunnen worden. De bestands ID van het STTR-bestand kan overgenomen worden in de Toepasbare regelcomponent, waarmee het STTR-bestand kan worden overgenomen in de Toepasbare-regelcomponent. Is sprake van een nieuwe werkzaamheid (al of niet op basis van gedownloade toepasbare regels), dan wordt die gekoppeld aan de juiste juridische activiteit (hiervoor is de Regels-bij-activiteiten-API nodig).
Met de toepasbare-regelscomponent stelt het bevoegd gezag toepasbare regels op. Toepasbare regels is het geheel van de bedrijfsregels, uitvoeringsregels, conversieregels en toeleidingsregels. Deze zijn gebaseerd op de analyse van wet- en regelgeving. Het feitelijk maken van toepasbare regels is het opstellen van vragenbomen door het vertalen van wet- en regelgeving in bedrijfsregels, uitvoeringsregels, interactieregels en toeleidingsregels. Er zijn twee soorten vragenbomen, de ene soort ondersteunt het oriënteren via vragenbomen (vergunningchecker) en de andere soort ondersteunt het opstellen en indienen (aanvraagformulier). Toepasbare regels kunnen op fouten gecontroleerd worden door opgestelde vragenbomen als STTR-bestand aan te bieden ter verificatie aan de landelijke voorziening. Vervolgens stuurt de landelijke voorziening een lijst met verificatiefouten.
Een opgestelde en geverifieerde set toepasbare regels wordt aangeboden aan de landelijke voorziening en opgenomen in de RTR. Hierbij wordt onderscheid gemaakt in het aanbieden van een nieuw set toepasbare regels, een gewijzigde set en een te verwijderen set.
Interactiepatronen Vergunning, Toezicht en Handhavingscomponent fysieke leefomgeving[bewerken]
Als een Verzoek (aanvraag, melding of informatieplicht) in de Landelijke voorziening succesvol is ingediend, ontvangt de gemeente een verzoeknotificatie dat er een verzoek klaarstaat om opgehaald te worden. De VTH-component haalt vervolgens het STAM-verzoek en ook de bijlagen op bij de landelijke voorziening. Als later nog bijlagen aan het Verzoek in de landelijke voorziening worden toegevoegd, haalt de gemeente alleen de toegevoegde bijlagen op.
Als bij opening van het Verzoek blijkt dat dit voor een ander bevoegd gezag of behandeldienst is bedoeld, dan stuurt de gemeente een opdracht naar de Landelijke voorziening om het bericht bij de juiste partij af te leveren.
Voor de behandeling van een verzoek kan het relevant zijn om te weten welke verzoeken eerder zijn ingediend op dezelfde locatie. Ook kan het interessant zijn om te zien welke verzoeken mogelijk bij een andere bestuurslaag zijn ingediend in een bepaald gebied. Informatie over dergelijke verzoeken wordt opgevraagd via de API van het verzoekenregister van DSO-LV. Op basis van meegegeven zoekcriteria worden metagegevens over ingediende verzoeken als resultaat teruggegeven.
Als een Verzoek (aanvraag of melding) in de landelijke voorziening succesvol is ingediend, ontvangt de omgevingsdienst een verzoeknotificatie dat er een verzoek klaarstaat om opgehaald te worden. De VTH-component haalt vervolgens het STAM-verzoek en ook de bijlagen op bij de landelijke voorziening. Als later nog documenten aan het Verzoek in de landelijke voorziening worden toegevoegd, haalt de behandeldienst alleen de toegevoegde documenten op.
Als bij opening van het Verzoek blijkt dat dit voor een ander bevoegd gezag of behandeldienst is bedoeld, dan stuurt de behandeldienst een opdracht naar de landelijke voorziening om het bericht bij de juiste partij af te leveren.
Voor de behandeling van een verzoek kan het relevant zijn om te weten welke verzoeken eerder zijn ingediend op dezelfde locatie. Ook kan het interessant zijn om te zien welke verzoeken mogelijk bij een andere bestuurslaag zijn ingediend in een bepaald gebied. Informatie over dergelijke verzoeken wordt opgevraagd via de API van het verzoekenregister van DSO-LV. Op basis van meegegeven zoekcriteria worden metagegevens over ingediende verzoeken als resultaat teruggegeven.
Als de gemeente met andere partners moet zaakgericht samenwerken aan de behandeling van een verzoek, start de gemeente vanuit de VTH-component een samenwerking in de landelijke voorziening (SWF). In de SWF geeft de gemeente aan met welke andere partijen aan dit verzoek wordt samengewerkt en welke rechten die partijen hebben. De SWF stuurt actieverzoeken naar de andere partijen om deel te nemen aan de samenwerking. De gemeente kan documenten uploaden met de SWF en de vertrouwelijkheid van documenten aangeven. Via de SWF kunnen alle deelnemende partijen notificaties en actieverzoeken naar elkaar sturen en documenten up- en downloaden. De gemeente kan de samenwerking wijzigen en stoppen. De gemeente zorgt dat als de samenwerking is gestopt, alle relevante informatie van de samenwerking wordt opgenomen in het eigen VTH-dossier. Tenslotte wordt de gestopte samenwerking na een vaste periode verwijderd uit de SWF.
Als een adviespartner moet zaakgericht samenwerken aan de behandeling van een Verzoek van een ander bevoegd gezag, ontvangt de adviespartner een actieverzoek daartoe van de SWF. De adviespartner accepteert het actieverzoek. De adviespartner heeft nu toegang tot de samenwerking en kan binnen de toegekende rechten het samenwerkdossier inzien. De adviespartner kan documenten uploaden met de SWF en de vertrouwelijkheid van documenten aangeven. Via de SWF kan de adviespartner notificaties en actieverzoeken naar de andere deelnemers sturen en documenten downloaden.
Als de behandeldienst met andere partners moet zaakgericht samenwerken aan de behandeling van een verzoek, start de behandeldienst vanuit de VTH-component een samenwerking in de landelijke voorziening (SWF). In de SWF geeft de behandeldienst aan met welke andere partijen aan dit verzoek wordt samengewerkt en welke rechten die partijen hebben. De SWF stuurt actieverzoeken naar de andere partijen om deel te nemen aan de samenwerking. De behandeldienst kan documenten uploaden met de SWF en de vertrouwelijkheid van documenten aangeven. Via de SWF kunnen alle deelnemende partijen notificaties en actieverzoeken naar elkaar sturen en documenten up- en downloaden. De behandeldienst kan de samenwerking wijzigen en stoppen. De behandeldienst zorgt dat als de samenwerking is gestopt, alle relevante informatie van de samenwerking wordt opgenomen in het eigen VTH-dossier. Tenslotte wordt de gestopte samenwerking na een vaste periode verwijderd uit de SWF.
Met de VTH-component stuurt de gemeente brieven, de beschikking en overige berichten per digitale post naar MijnOverheid.nl. Brieven, beschikking en overige berichten worden per post verstuurd naar initiatiefnemer, indiener en belanghebbende.
Met de VTH-component stuurt de behandeldienst brieven, de beschikking en overige berichten per digitale post naar MijnOverheid.nl. Brieven, beschikking en overige berichten worden per post verstuurd naar initiatiefnemer, indiener en belanghebbende.
Team vergunningverlening van de gemeente stelt de kennisgeving buitenplanse omgevingsplanactiviteit (BPOA), de kennisgeving van een aanvraag of kennisgeving van een besluit, en het besluit zelf beschikbaar via de landelijke voorziening DROP. Dit heet de publicatie. De wijze waarop Team vergunningen publiceert kan via de DROP-toepassing of via de 3PAS-API.
De afdeling van de Behandeldienst van de gemeente stelt de kennisgeving buitenplanse omgevingsplanactiviteit (BPOA), de kennisgeving van een aanvraag of kennisgeving van een besluit beschikbaar via de landelijke voorziening DROP. Dit heet de publicatie. De wijze waarop de afdeling publiceert kan via de DROP-toepassing of via de 3PAS-API. De gemeente blijft verantwoordelijk voor de publicatie van het genomen besluit.
Het geheel van mensen, middelen en maatregelen, gericht op de informatiebehoefte van de organisatie.
Een beschrijving van de structuur en interactie van de applicaties die belangrijke bedrijfsfuncties ondersteunen en gegevens beheren.
De fundamentele concepten of eigenschappen van een systeem in zijn omgeving belichaamd in zijn elementen, relaties en in de principes van zijn ontwerp en evolutie.
Een computerprogramma om een specifieke taak uit te voeren die geen betrekking heeft op de werking van de computer zelf.
De fundamentele concepten of eigenschappen van een systeem in zijn omgeving belichaamd in zijn elementen, relaties en in de principes van zijn ontwerp en evolutie.
De GEMeentelijke ModelArchitectuur met een verzameling samenhangende kaders, richtlijnen, referentiemodellen en standaarden die gemeenten helpt bij het inrichten van hun IT-omgeving en processen.
Afkorting van 'application programming interface': een manier om twee of meer computerprogramma's met elkaar te laten communiceren. Het is een soort software-interface die een dienst aanbiedt aan andere stukjes software.
Reeks opeenvolgend uit te voeren activiteiten die bijdraagt aan een specifiek resultaat, zoals de levering van een Product of Dienst.
Een samenhangende hoeveelheid werk met een welgedefinieerde aanleiding en een welgedefinieerd eindresultaat, waarvan kwaliteit en doorlooptijd bewaakt moeten worden.
Onderdeel van de bedrijfsarchitectuur met principes en afspraken voor het inrichten van bedrijfsprocessen.
Een systeem waarbinnen organisaties via afspraken, standaarden en/of voorzieningen samenwerken om bepaalde functionaliteit te realiseren.
Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat.
Betekenisvolle gegevens.
Groepering van services die aan afnemers worden aangeboden, met als doel het bevorderen van uniformiteit en efficiëntie binnen de overheid.
Een type applicatiecomponent dat binnen een referentiearchitectuur benoemd is als elementair bouwblok
Een standaard set van beveiligingseisen die is gedefinieerd op basis van generieke schades en dreigingen voor de overheid
Alle belanghebbenden van overheidsdienstverlening in de ruimste zin van het woord.
Een systeem waarbinnen organisaties via afspraken, standaarden en/of voorzieningen samenwerken om bepaalde functionaliteit te realiseren.
Een document met erkende afspraken, specificaties of criteria over een product, een dienst of een methode.
Een eis die geldt voor een specifiek informatiesysteem of onderdeel daarvan binnen de architectuur.
Een eis die geldt voor een specifiek informatiesysteem of onderdeel daarvan binnen de architectuur.
Een door de overheid officieel aangewezen registratie met daarin gegevens van hoogwaardige kwaliteit, die door alle overheidsinstellingen verplicht en zonder nader onderzoek, worden gebruikt bij de uitvoering van publiekrechtelijke taken.
Iedere persoon, organisatie of functionele eenheid die gebruik maakt van een informatiesysteem.
Een afgebakende prestatie van een persoon of organisatie (de dienstverlener), die voorziet in een behoefte van haar omgeving (de dienstafnemer(s)).
Een door een applicatie geleverde dienst (te gebruiken via applicatieinterfaces).
Gestructureerde beschrijving van de structuur, semantiek en de eigenschappen van informatie over dingen in de werkelijkheid.
Het opleggen van een bepaalde norm of standaard voor het ontwerp, de constructie, het testen of gebruiken van een product of proces.
Een document met erkende afspraken, specificaties of criteria over een product, een dienst of een methode.
Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat.
Object met gegevens die door de bron is bedoeld voor ontvangst door een of meer ontvangende actoren of systemen.
Betekenisvolle gegevens.
De door een aanbieder aan afnemers verstrekte gegevens over binnen zijn domein plaatsgevonden gebeurtenissen
Extensible Markup Language (XML) is een standaard van het World Wide Web Consortium voor de syntaxis van formele opmaaktalen waarmee men gestructureerde gegevens kan weergeven in de vorm van platte tekst.
Een samenhangende hoeveelheid werk met een welgedefinieerde aanleiding en een welgedefinieerd eindresultaat, waarvan kwaliteit en doorlooptijd bewaakt moeten worden.
Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat. (Synoniem van: Data )
Afkorting voor de Representational State Transfer architectuurstijl voor gedistribueerde hypermedia systemen
JavaScript Object Notation (JSON) is een lichtgewicht, op tekst gebaseerd, taalonafhankelijk gegevensuitwisselingsformaat.
Een samenhangende set Diensten, Bedrijfsobjecten en/of Representaties die onder in een Overeenkomst beschreven voorwaarden kan worden afgenomen.
Afkorting voor 'Standaard Uitwisseling Formaat': een berichtenstandaard met afspraken over de basisprincipes voor het uitwisselen van gegevens tussen applicaties in het gemeentelijke veld.
Het vermogen van organisaties (en hun processen en systemen) om effectief en efficiënt informatie te delen met hun omgeving.
Groepering van services die aan afnemers worden aangeboden, met als doel het bevorderen van uniformiteit en efficiëntie binnen de overheid.
De herbruikbare vorm van een oplossing voor een ontwerpprobleem
Deze pagina is het laatst bewerkt op 6 okt 2023 om 03:54.
Voor vragen over de GEMMAreferentiearchitectuur, stuur een bericht naar gemmaonline@vng.nl of stel direct een vraag in de groep Regie op ICT op het forum van VNG.
De GEMeentelijke ModelArchitectuur met een verzameling samenhangende kaders, richtlijnen, referentiemodellen en standaarden die gemeenten helpt bij het inrichten van hun IT-omgeving en processen.
Sjabloonoplossing voor de architectuur van een bepaald domein.
Object met gegevens die door de bron is bedoeld voor ontvangst door een of meer ontvangende actoren of systemen.
