Zodat mijn zaak in behandeling genomen kan worden dan wel behandeld kan worden

Zodat ik geen enkele zaak over het hoofd zie

En mijn zaken kan raadplegen

En kan zien welke zaken lopen en welke zaken zijn afgesloten.

... zodat die automatisch kan verwerkt worden en eigendom wordt van een proceseigenaar.

ASCM = actieservicecentrummedewerker

...zodat de gemeente op de hoogte is van de overlast en hierop kan acteren.

Shortcuts

• RGBZ Mapping
• testdata (.json)

Definition of done

• er is een OAS 3.0 specificatie, afgestemd met leveranciers van ZRC/e-Suite
• de specificatie is gepubliceerd leesbaar
• er is een referentieimplementatie
• [ ] er is functionele documentatie conform het DSO-patroon

Acceptatiecriteria

Uit de algemene uitgangspunten:

• Voldoet aan RGBZ 2.0
• Voldoet aan GEMMA 2.0
• de DSO URI- en API-strategie worden gevolgd

Taken

• Opstellen welke velden bij een melding horen [@MarcelMoerman]
• Aanleveren testdata [@MarcelMoerman]
• Schrijven (unit) test voor referentie-implementatie [@sergei-maertens]
• Implementeren in referentie-implementatie [@sergei-maertens]
• Genereren/opstellen van OAS 3.0 [@sergei-maertens]
• [ ] Functionele documentatie [@michielverhoef ]
• Human Readable publiceren Open API Specificatie (v.3.0) [?]

Test

Zodat ik geen enkele ontwikkeling binnen een zaak over het hoofd zie

En kennis kan nemen van de laatste ontwikkeling(en) binnen mijn zaak

En tijdig de input kan leveren waar een behandelaar om vraagt

En tijdig kan reageren of een vraag kan stellen.

... zodat ik niet elke dag hoef te controleren op nieuwe meldingen.

• geefLijstZaken
• zoekparameter bsn initiator
• zoekparameter zaaktype
• zaakbevragingen koppelvlak

Zodat ik kan zien wie er in welke rol betrokken zijn bij mijn zaak

En kan zien wat de laatste status is

En kennis kan nemen van de beslistermijn van een zaak

En kan zien wie ik kan bellen als ik een vraag heb

En kan zien of de zaak binnen de afgesproken termijn is behandeld

En kan zien welke andere zaken een relatie hebben met mijn zaak.

Zodat
Ik toestemming krijg voor aan activiteit
Ik de/een overheid een activiteit kan laten uitvoeren voor mij
Ik iets kan laten weten aan de/een overheid

zodat ik proactief en real-time op de hoogte gesteld wordt van de voortgang van mijn zaak.

gerelateerd aan #397

... zodat de melding kan worden gerouteerd.

Links

• ZRC pull request
• ZTC pull request
• integratietests
• #296

API spec aanpassingen
(nog) geen

Definition of ready

• Iedereen in het team begrijpt de user story en ziet de toegevoegde waarde.
• Userstory is ingevuld op template architectuurschets
• Is klein genoeg (maximaal 1/5 van sprint)
• Product Owner akkoord
• Voorzien van acceptatiecriteria (duidelijk en testbaar)
• Voorzien van definition of Done (duidelijk en testbaar)
• Idee hebben van hoe deze user story kan worden gedemonstreerd.
• Vastgelegd Github en in geplaatst in kolom ready
• Userstory is voorzien van veldmapping naar RGBZ2
• Userstory past op wenselijk gebruik ZGW volgens GEMMA 2

(Op termijn ook -> Business Waarde en story points zijn bepaald.)

Definition of done

• er is een OAS 3.0 specificatie
• de specificatie is gepubliceerd leesbaar
• er is een referentieimplementatie
• de DSO URI- en API-strategie worden gevolgd

Acceptatiecriteria
Uit de algemene uitgangspunten:

• Voldoet aan RGBZ 2.0
• Voldoet aan GEMMA 2.0

Taken

• Architectuurschets opleveren [Marcel Moerman]
• Beschrijven welke data er wordt gemuteerd bij uitvoeren van deze functie [verantwoordelijke]
• Aanleveren testdata [verantwoordelijke]
• Schrijven (unit) test voor referentie-implementatie [verantwoordelijke]
• Implementeren in referentie-implementatie [verantwoordelijke]
• Genereren/opstellen van OAS 3.0 [verantwoordelijke]
• Human Readable publiceren Open API Specificatie (v.3.0) [verantwoordelijke]

Architectuurschets
Architectuurschets is hier #180 te vinden.

Voor de selectie van de behandelaar wordt er uit de ZTC een relevant Zaak_type selecteert, de zaak kan worden geüpdate met de juiste Organisatorische-eenheid.

Select op ZTC API

Update op ZRC API

zodat ik interoperabiliteit tussen leveranciers kan bewerkstelligen en leveranciers kan bewegen in de richting van Common ground (Silo's openen)

zodat het zaakdossier correct is en de zaakdocumenten in het correcte dossier zitten

DRC kan dit al, ZRC nog niet.

zodat een gespecialiseerde organisatie de zaak beter kan behandelen dan een generieke afdeling

Context: een gemeente heeft het VTH proces uitbesteed aan een Omgevingsdienst. Alle relevante aanvragen en zaken die bij de gemeente binnenkomen moeten rechtstreeks naar de Omgevingsdienst doorgestuurd kunnen worden. Bijvoorbeeld gemeente Moerdijk die rechtstreeks zaken aanmaakt bij de OMWB.

...
zodat ik centraal alle overheden kan afhandelen binnen 1 loket
en direct kan beschikken over up-to-date informatie

zodat ik inzicht heb in de situatie van de klant (mits toegestaan volgens AVG/doelbinding) en de klant optimaal kan ondersteunen.

• geefLijstZaken op bsn
• onderdeel zaakbevragingen koppelvlak
• architectuur document
• ..

zodat de laatste zaakgegevens ook in het zaaksysteem komen te staan

...zodat ik weet of mijn melding naar wens wordt opgepakt.

Definition of ready

• Iedereen in het team begrijpt de user story
• Is klein genoeg (maximaal 1/5 van sprint)
• Product Owner akkoord
• Voorzien van acceptatiecriteria (duidelijk en testbaar)
• Voorzien van Definition of Done (duidelijk en testbaar)
• Voorzien van taken
• Idee hebben van hoe deze user story kan worden gedemonstreerd.
• Userstory is ingevuld op template architectuurschets
• Userstory is voorzien van veldmapping naar RGBZ2
• Userstory past op wenselijk gebruik ZGW volgens GEMMA 2
• Vastgelegd Github en in geplaatst in kolom ready

Definition of done

• er is een OAS 3.0 specificatie, afgestemd met leveranciers van ZRC/e-Suite
• de specificatie is gepubliceerd leesbaar
• er is een referentieimplementatie
• er is functionele documentatie conform het DSO-patroon
• de DSO URI- en API-strategie worden gevolgd

Acceptatiecriteria

Uit de algemene uitgangspunten:

• Voldoet aan RGBZ 2.0
• Voldoet aan GEMMA 2.0

Taken

• Opstellen welke velden bij een melding horen [verantwoordelijke]
• Aanleveren testdata [verantwoordelijke]
• Schrijven (unit) test voor referentie-implementatie [verantwoordelijke]
• Implementeren in referentie-implementatie [verantwoordelijke]
• Genereren/opstellen van OAS 3.0 [verantwoordelijke]
• Functionele documentatie [verantwoordelijke]
• Human Readable publiceren Open API Specificatie (v.3.0) [verantwoordelijke]

Proces

In Amsterdam is een melding die binnenkomt via het signalen platform anoniem. Als een melder op de hoogte wil worden gehouden is er de mogelijkheid om e-mailadres of telefoonnummer mee te geven in de melding. Op deze manier kan er contact kan worden opgenomen voor toelichting en kan er terugkoppeling worden gegeven over de voortgang.

Een melding wordt nooit geregistreerd op persoon.
Er worden vooralsnog geen publieke lijsten / kaarten gepubliceerd met meldingen en de status.

Dit is anders in de situatie waarbij meldingen binnenkomen via een platform als "verbeter de buurt", die de API van signalen gebruikt, hier wordt wel openbare feedback gegeven op de meldingen en afhandeling.

Architectuur

De globale architectuur voor de usecase is beschreven in de Amsterdamse oplossings-schets.
Deze is hier te vinden >> Documentatie

Filters zijn op twee ingangen te gebruiken voor selecties,

Selecties op ZRC API

Selecties op MOR API

...zodat ik toestemming krijg om te parkeren en mijn evenement kan houden.

zodat anderen hiervan kennis kunnen nemen zonder dat zij toegang moeten hebben tot de vakapplicatie

zodat het zaakdossier correct is en de zaakdocumenten in het correcte dossier zitten

...
zodat ik weet welke informatie ik hier kan vinden

... zodat ik zie welke meldingen moeten opgevolgd worden.

• ASCM = actieservicecentrummedewerker (naamgeving Amsterdam)
• KCC = klantcontactcentrum (naamgeving Haarlem)

zodat ik inzage krijg in mijn zaak.

zodat het zaakdossier volledig gemaakt wordt

... zodat ik aan privacy en beheer regels kan voldoen.

Concrete invulling hiervan:

• #66

Let op! Dit kunnen ook gearchiveerde dossiers zijn.

** LET OP MOET SLICED WORDEN **

Definition of ready

• Iedereen in het team begrijpt de user story
• Is klein genoeg (maximaal 1/5 van sprint)
• Product Owner akkoord
• Voorzien van acceptatiecriteria (duidelijk en testbaar)
• Voorzien van Definition of Done (duidelijk en testbaar)
• Voorzien van taken
• Idee hebben van hoe deze user story kan worden gedemonstreerd.
• Userstory is ingevuld op template architectuurschets
• Userstory is voorzien van veldmapping naar RGBZ2
• Userstory past op wenselijk gebruik ZGW volgens GEMMA 2
• Vastgelegd Github en in geplaatst in kolom ready

Definition of done

• er zijn 1 of meer aanbevolen patronen beschreven voor autorisatie binnen de ZDS 2.0
  • hoe wordt omgegaan met scopes
  • hoe wordt omgegaan met data visibility, bij voorkeur kan requester zelf beperken
  • welke methoden zijn aanbevolen om scopes aan autorisaties toe te kennen
  • welke autorisatiemechanismen worden aanbevolen
• de OAS 3.0 specificatie is uitgebreid met wat nodig is voor autorisatie
• deze specificatie is gepubliceerd
• de referentieimplementatie ondersteunt de aanbevolen patronen
• er is functionele documentatie waarin de patronen functioneel worden beschreven

Acceptatiecriteria

Uit de algemene uitgangspunten:

• Voldoet aan RGBZ 2.0
• Voldoet aan GEMMA 2.0
• de DSO URI- en API-strategie worden gevolgd
• Standaarden van de Pas-toe-of-leg uit lijst van Forum Standaardisatie worden gevolgd

Taken

• Beschrijven welke mechanismen gewenst zijn [ ]
• Analyse welke uitbreiding van de OAS nodig is [ ]
• Schrijven (unit) test voor referentie-implementatie [@sergei-maertens]
• Implementeren in referentie-implementatie [@sergei-maertens]
• Genereren/opstellen van OAS 3.0 [@sergei-maertens]
• Functionele documentatie [@michielverhoef ]
• Human Readable publiceren Open API Specificatie (v.3.0) [?]

zodat ik op verzoek van de gemeente mijn lopende zaak met documenten kan aanvullen.

het data model van het ZRC en DRC is wel multitenant maar onderdelen als audittrail, logging, etc niet. Op dit moment is het zo neergezet voor 380 implementaties, niet 1 met 380 gebruikende organisaties. Dit kan natuurlijk wel, maar is dan uitbreiding in fuctionaliteit.

zodat er een gezamenlijke open source basis is voor het toepassen van zaakgerichte componenten.

...zodat ik voldoende details weet om de melding op te volgen.

Definition of done

• er is een OAS 3.0 specificatie, afgestemd met leveranciers van ZRC/e-Suite
• de specificatie is gepubliceerd leesbaar
• er is een referentieimplementatie
• er is functionele documentatie conform het DSO-patroon
• de DSO URI- en API-strategie worden gevolgd

Acceptatiecriteria

Uit de algemene uitgangspunten:

• Voldoet aan RGBZ 2.0
• Voldoet aan GEMMA 2.0

Taken

• Beschrijven welke data nodig is voor deze functie [ @MarcelMoerman ]
• Aanleveren testdata [ @MarcelMoerman ]
• Schrijven (unit) test voor referentie-implementatie [ @sergei-maertens ]
• Implementeren in referentie-implementatie [ @sergei-maertens ]
• Genereren/opstellen van OAS 3.0 [ @sergei-maertens ]
• Functionele documentatie [ @michielverhoef ]
• Human Readable publiceren Open API Specificatie (v.3.0) [ @sergei-maertens ]

Architectuurschets
Architectuurschets is hier #180 te vinden.

Voor wegschrijven locatie en overige informatie wordt er gebruik gemaakt van uitbreiding op ZAAK.objecttype

Update op ZRC API

Definition of ready

• Iedereen in het team begrijpt de user story
• Is klein genoeg (maximaal 1/5 van sprint)
• Product Owner akkoord
• Voorzien van acceptatiecriteria (duidelijk en testbaar)
• Voorzien van Definition of Done (duidelijk en testbaar)
• Voorzien van taken
• Idee hebben van hoe deze user story kan worden gedemonstreerd.
• Userstory is ingevuld op template architectuurschets
• Userstory is voorzien van veldmapping naar RGBZ2
• Userstory past op wenselijk gebruik ZGW volgens GEMMA 2
• Vastgelegd Github en in geplaatst in kolom ready

Definition of done

• er is een OAS 3.0 specificatie
• de specificatie is gepubliceerd leesbaar
• er is een referentieimplementatie
• de DSO URI- en API-strategie worden gevolgd

Acceptatiecriteria
Uit de algemene uitgangspunten:

• Voldoet aan RGBZ 2.0
• Voldoet aan GEMMA 2.0

Taken

• Opstellen welke velden bij een opvraag zaken en statussen [@ppcjansen]
• Aanleveren testdata [@ppcjansen]
• Schrijven (unit) test voor referentie-implementatie [@joeribekker]
• Implementeren in referentie-implementatie [@joeribekker]
• Genereren/opstellen van OAS 3.0 [@joeribekker]
• Functionele documentatie [@michielverhoef ]
• Human Readable publiceren Open API Specificatie (v.3.0) [?]

Zodat ik de inhoud van het document kan zien.

Definition of ready

• Iedereen in het team begrijpt de user story
• Is klein genoeg (maximaal 1/5 van sprint)
• Product Owner akkoord
• Voorzien van acceptatiecriteria (duidelijk en testbaar)
• Voorzien van Definition of Done (duidelijk en testbaar)
• Voorzien van taken
• Idee hebben van hoe deze user story kan worden gedemonstreerd.
• Userstory is ingevuld op template architectuurschets
• Userstory is voorzien van veldmapping naar RGBZ2
• Userstory past op wenselijk gebruik ZGW volgens GEMMA 2
• Vastgelegd Github en in geplaatst in kolom ready

...
zodat ik centraal alle overheden kan afhandelen binnen 1 loket

Zodat ik kennis kan nemen van de status van mijn zaak en bijbehorende documenten

En kan zien of er een of meer activiteiten van mijn kant worden verwacht

En een genomen besluit en bijbehorende documenten kan inzien

En klantcontacten kan raadplegen.

Zie projectplan ZDS 2.0 common ground

...zodat ik weet wat er speelt of dat een melding al gedaan is.

Definition of done

• er is een OAS 3.0 specificatie, afgestemd met leveranciers van ZRC/e-Suite
• de specificatie is gepubliceerd leesbaar
• er is een referentieimplementatie
• de DSO URI- en API-strategie worden gevolgd

Acceptatiecriteria

Uit de algemene uitgangspunten:

• Voldoet aan RGBZ 2.0
• Voldoet aan GEMMA 2.0

Taken

• Architectuurschets opleveren [Marcel Moerman]
• Beschrijven welke data / operaties bij deze functie nodig zijn [Marcel Moerman]
• Aanleveren testdata [verantwoordelijke]
• Schrijven (unit) test voor referentie-implementatie [verantwoordelijke]
• Implementeren in referentie-implementatie [verantwoordelijke]
• Genereren/opstellen van OAS 3.0 [verantwoordelijke]
• Human Readable publiceren Open API Specificatie (v.3.0) [verantwoordelijke]

Architectuurschets
Architectuurschets is hier #180 te vinden.

Korte beschrijving uitwerking
Deze operatie verondersteld een GEO.Extensie op de database, hiermee kunnen er selecties worden gedaan op basis van oa. geometrie.

Anoniem: Geef alle meldingen terug binnen een straal van x meter van deze punt op de kaart.
Ingelogd: Geef alle meldingen terug binnen een straal van x meter rond mijn adres.

Als voorbeeld kan de GEO.Search op https://api.data.amsterdam.nl/api/swagger/?url=/geosearch/docs/geosearch.yml#/ dienen.

READ op ZRC API met filter op

Zodat mijn zaak in behandeling genomen kan worden dan wel verder behandeld kan worden

zodat deze in het zaaksysteem opgeslagen kan worden (en alle relevante) betrokkenen op de hoogte gebracht kunnen worden

...zodat ik weet of de melding al is opgepakt of afgehandeld.

... zodat ik deze meldingen kan oplossen.

zodat ik de voortgang kan volgen en nieuwe informatie kan toevoegen.
Bepaling prioriteit door PO

• verbreding of verdieping API's
• stimuleert gebruik door gemeenten
• stimuleert gebruik door leveranciers

... eventueel nog toelichting door PO

Definition of ready

• Iedereen in het team begrijpt de user story
• de gewenste (aanvulling op de) functionaliteit van de API's duidelijk en beschreven is.
• Is klein genoeg (maximaal 1/5 van sprint)
• Product Owner akkoord en voorzien van prioriteit (mag alleen afgevinkt worden door PO)
• Idee hebben van hoe deze user story kan worden gedemonstreerd.
• Userstory is voorzien van een analyse (met daarin architectuur, IM, technische beslissingen afgestemd met team)
• Vastgelegd in Github en geplaatst in kolom ready

Definition of done

• Er is een OAS 3.0 specificatie
• Er is een referentieimplementatie
• Er zijn tests aanwezig die de wijziging aantonen
• De technische specificatie (standaard.md) is gepubliceerd leesbaar

Acceptatiecriteria

• De DSO URI- en API-strategie worden gevolgd of afwijkingen zijn vastgelegd als ontwerp keuze
• Eventueel gemaakte ontwerp keuzes zijn gedocumenteerd
• Er zijn geen bekende GEMMA tegenstrijdigheden of afwijkingen zijn vastgelegd.

Taken

• Implementeren in referentie-implementatie [verantwoordelijke]
• Schrijven (unit) test voor referentie-implementatie [verantwoordelijke]
• Genereren/opstellen van OAS 3.0 [verantwoordelijke]
• Human Readable publiceren Open API Specificatie (v.3.0) [verantwoordelijke]

zodat een persoon of vertegenwoordiger van een persoon met een zaak bij de/ een overheid`inzage heeft in de gegevens en documenten van deze zaak

...zodat de actuele status voor de betrokkenen inzichtelijk is.

Definition of ready

• Iedereen in het team begrijpt de user story
• Is klein genoeg (maximaal 1/5 van sprint)
• Product Owner akkoord
• Voorzien van acceptatiecriteria (duidelijk en testbaar)
• Voorzien van Definition of Done (duidelijk en testbaar)
• Voorzien van taken
• Idee hebben van hoe deze user story kan worden gedemonstreerd
• Userstory is ingevuld op template architectuurschets
• Userstory is voorzien van veldmapping naar RGBZ2
• Userstory past op wenselijk gebruik ZGW volgens GEMMA 2
• Vastgelegd Github en in geplaatst in kolom ready

Definition of done

• er is een OAS 3.0 specificatie, afgestemd met leveranciers van ZRC/e-Suite
• de specificatie is gepubliceerd leesbaar
• er is een referentieimplementatie
• er is functionele documentatie conform het DSO-patroon
• de DSO URI- en API-strategie worden gevolgd

Acceptatiecriteria

Uit de algemene uitgangspunten:

• Voldoet aan RGBZ 2.0
• Voldoet aan GEMMA 2.0

Taken

• Opstellen welke velden bij een melding horen [verantwoordelijke]
• Aanleveren testdata [verantwoordelijke]
• Schrijven (unit) test voor referentie-implementatie [verantwoordelijke]
• Implementeren in referentie-implementatie [verantwoordelijke]
• Genereren/opstellen van OAS 3.0 [verantwoordelijke]
• Functionele documentatie [verantwoordelijke]
• Human Readable publiceren Open API Specificatie (v.3.0) [verantwoordelijke]

... omdat er door omstandigheden een verandering kan optreden in de planning moet een gedane belofte (servicenorm) kunnen worden aangepast door een medewerker ASCM of de behandelende Back-office. De aanpassing gaat altijd gepaard met een toelichting over de gewijzigde status / situatie.

ASCM = Actie Service Centrum Medewerker

Definition of ready

• Iedereen in het team begrijpt de user story
• Is klein genoeg (maximaal 1/5 van sprint)
• Product Owner akkoord
• Voorzien van acceptatiecriteria (duidelijk en testbaar)
• Voorzien van Definition of Done (duidelijk en testbaar)
• Voorzien van taken
• Idee hebben van hoe deze user story kan worden gedemonstreerd.
• Userstory is ingevuld op template architectuurschets
• Userstory is voorzien van veldmapping naar RGBZ2
• Userstory past op wenselijk gebruik ZGW volgens GEMMA 2
• Vastgelegd Github en in geplaatst in kolom ready

Definition of done

• er is een OAS 3.0 specificatie, afgestemd met leveranciers van ZRC/e-Suite
• de specificatie is gepubliceerd leesbaar
• er is een referentieimplementatie
• er is functionele documentatie conform het DSO-patroon
• de DSO URI- en API-strategie worden gevolgd

Acceptatiecriteria

Uit de algemene uitgangspunten:

• Voldoet aan RGBZ 2.0
• Voldoet aan GEMMA 2.0

Taken

• Beschrijven welke data er wordt gemuteerd bij uitvoeren van deze functie [verantwoordelijke]
• Aanleveren testdata [verantwoordelijke]
• Schrijven (unit) test voor referentie-implementatie [verantwoordelijke]
• Implementeren in referentie-implementatie [verantwoordelijke]
• Genereren/opstellen van OAS 3.0 [verantwoordelijke]
• Functionele documentatie [verantwoordelijke]
• Human Readable publiceren Open API Specificatie (v.3.0) [verantwoordelijke]

Architectuur

De globale architectuur voor de usecase is beschreven in de Amsterdamse oplossings-schets.
Deze is hier te vinden >> Documentatie

Update op ZRC API

zodat ik een volledig beeld kan krijgen van klantcontacten die in het kader van de afhandeling van een zaak hebben plaatsgevonden

zodat ik een (vervolg)actie kan uitvoeren