Uniforme registratie van zaken
Een standaardwijze om een zaak te registereren
Auteur: Joeri Diederen | Status: In voorbereiding
Aanleiding
Bij het aanmaken van een zaak wordt een bericht richting de ZGW-API gestuurd. De definitie van het zaakobject schrijft voor welke waarden verplicht zijn. Voor passende dienstverlening en optimaal zaakgericht werken zijn meer voorschriften nodig, om maximaal dienstverlenend te zijn.
Mogelijke doeleinden zijn:
Het weergeven van een zaak en haar details op een klantportaal
Het weergeven van een zaak binnen een KCC-applicatie
Het weergeven van data binnen een rapportage-tool
Constateringen
Invulling
In de praktijk wordt opgemerkt dat door verschillende leveranciers verschillende invullingen worden gegeven aan de beoogde inhoud van bepaalde velden. Dat beperkt standaardisatie richting bijvoorbeeld klantportalen.
Timing
Ook opgemerkt wordt dat de momenten waarop data in Open Zaak wordt geplaatsts verschilt. Sommige taakapplicaties posten informatie direct wanneer deze beschikbaar is, anderen per statusovergang, en anderen pas als de zaak afgesloten is.
Gevolg
Omdat de richtlijnen over invulling, timing en operaties niet strak gedefineerd zijn, worden deze per leverancier anders geïnterpreteerd.
Dat leidt tot dubbele gesprekken met leveranciers, om ze te bewegen te voldoen aan hun lokale gewenste subset. Voor een leverancier met een landelijke afzetmarkt is dat problematisch. En, als het ene processysteem optimaal werkt met een specifiek portaal, omdat het de waarden registreert die in het portaal weergegeven worden, is dat portaal niet meer goed vervangbaar.
De vele losse operaties leiden ook tot terughoudendheid in de adoptie van de ZGW-API, ook bij product owners, omdat veel ervaring rondom het zaakgericht werken vereist is om de data op de juiste manier te registreren.
Doelstellingen
Handelingen definiëren rondom de levenscyclus van een zaak, van creatie tot afhandeling
Voorbeeldberichten documenteren rondom registratie vanuit deze handelingen
Optioneel: Wellicht eenvoudiger gebruik door de creatie van convenience API's
Principes
Een zaak heeft altijd een actuele behandelaar of afdeling
De doorlooptijden van een zaak worden bij iedere statusupdate gecontroleerd
Het procesobject wordt gebruikt als er een product of dienst geleverd wordt
Zaak aanmaken
Statusupdate
Betrokkene update
Resultaat update
Document registreren
Documenten locken
Object relateren (BAG, ORC, Etc)
Zaak opschorten, hervatten, verlengen (datumberekening uitwerken)
Besluit registreren (met procesobject)
Zaak relateren
Twijfelachtig
Contactmoment aanmaken
Best practices
GET metadata
Creeer zaak
identificatie
Wordt automatisch gegenereerd
bronorganisatie*
omschrijving
Klant ziet dit op portaal
toelichting
zaaktype*
registratiedatum
Indien niet opgegeven, wordt de datum van vandaag gebruikt.
verantwoordelijkeOrganisatie*
startdatum*
einddatumGepland
Berekenen op basis van startdatum + ZTC servicenorm
uiterlijkeEinddatumAfdoening
Berekenen op basis van startdatum + ZTC doorlooptijd
publicatiedatum
communicatiekanaal
Conform referentielijsten-API-values
productenOfDiensten
vertrouwelijkheidaanduiding
Indien niet opgegeven, wordt de waarde uit de ZTC gebruikt.
betalingsindicatie
laatsteBetaaldatum
Als er sprake is van betaling
zaakgeometrie
Als de zaak een locatie heeft
verlenging
opschorting
selectielijstklasse
hoofdzaak
Als er sprake is van een hoofdzaak
relevanteAndereZaken
Als er sprake is van andere zaken
kenmerken
archiefnominatie
Inherited?
archiefstatus
archiefactiedatum
opdrachtgevendeOrganisatie
Optioneel
processobjectaard
Joeri Bekker
startdatumBewaartermijn
Niet in deze fase
processobject
Joeri Bekker
Relateer status
zaak*
statustype*
datumStatus*
statustoelichting
Optioneel
gezetdoor
Optioneel
Relateer documenten
zaak
informatieobject
Relateer zaakobjecten
zaak
object
objectType
Creeer contactmoment
Relateer Rollen
Let op:
Verwerk altijd de INITIATOR Verwerk altijd de BEHANDELAAR of ORGANISATIE-ONDERDEEL ZAC: we leggen bij betrokkeneIdentificatie alleen het BSN, KvK, Vestigingsnummer vast
Hoe om te gaan met Open Klant in relatie tot het vastleggen van deze klantgegevens, mag dat als kopie aan de zaak, of moet dat als verwijzing naar de bron? Welke data leg je standaard vast? Hoe gaan we om met correspondentie-adressen? Waar wordt het mailadres van de klant opgehaald?
Relateer rol natuurlijk persoon
zaak*
betrokkene
Alleen als je gebruik maakt van HaalCentraal en of KvK-API. Dit moet een keuze zijn denk ik, want je wil werken met de gegeven die de klant heeft goedgekeurd in de aanvraag
betrokkeneType*
Altijd vullen
afwijkendeNaamBetrokkene
Bespreken
roltype*
Altijd vullen
roltoelichting*
Bespreken, verplicht veld in spec
indicatieMachtiging*
contactpersoonRol
Als er sprake is van een contactpersoon, relatie met Open Klant?
betrokkeneIdentificatie
Object [natuurlijk persoon]
Object contactpersoon
emailadres
Idealiter zou je hier relateren naar de 'partij' in Open Klant, áls je een actueel mailadres wilt gebruiken. Waar leggen we die relatie vast?
functie
telefoonnummer
naam
Object natuurlijk persoon
ipBsn
Als bekend
anpIdentificatie
Voor eIDAS?
inpA_nummer
Geen output van authenticatiemethode toch? Dus moet handmatig opgevoerd worden. Waar?
geslachtnaam
voorvoegselGeslachtsnaam
voorletters
voornamen
geslachtsaanduiding
geboortedatum
verblijfsadres
Object, waar put SD / Xential uit haar informatie voor een briefhoofd. Is dat specifiek samengesteld per zaak, of wordt dat opgehaald?
subVerblijfBuitenland
Object verblijfsadres subVerblijfBuitenland
Last updated