Vanuit een applicatie (ZsC) is er de wens om zaakgegevens op te vragen vanuit een BSN. De applicatie is al enige tijd gewend dit te doen, dit is namelijk ook prima mogelijk binnen het reguliere sectormodel ZKN wat ze al een aantal jaar gebruiken. Nu willen we voor die applicatie de overstap maken naar de ZSDMS services (en daarmee gaan werken conform de uitgeleverde ZSDMS XSD’s/WSDL’s). Hierdoor lijkt ‘geef zaakdetails’ voor het bovenstaande de meest geschikte optie, echter wordt volgens de specificatie hierin zaakidentificatie verplicht gesteld in de vraag. Dit terwijl de applicatie die juist wil gaan opvragen vanuit een BSN (BSN is slechts een voorbeeld, dit kan natuurlijk ook vestigingsnummer of postcode/huisnummer zijn). Wat is volgens jullie de manier om dit te tackelen? Moet er een nieuwe zaakservice komen om zaakgegevens op te vragen op basis van andere zoekcriteria (naast de 'geefZaakdetails'?. En hoe dienen we dit te ondersteunen in de huidige (tussen)situatie: "Dient de applicatie voor vragen die ze willen stellen en die nog niet volgens de ZSDMS specificaties ondersteund worden maar gewoon de reguliere ZKN services te blijven gebruiken?"
wo, 16-07-2014 - 16.13u
#1
Vragen op BSN, gebruik ik daarvoor geefZaakdetails?
Mijn persoonlijke mening: - 'Lange' termijn (als structurele oplossing) moet er een extra bericht komen 'GeefZakenVanBurger' (of iets dergelijks), die alle zaken geeft, waarvoor de burger initiator is (of ook betrokkene? -- scope discussie). 'geefZaakdetails' zou dan weer over het resultaat van de eeste vraag gesteld moeten kunnen worden (of we moeten voldoende velden teruggeven bij 'GeefZakenVanBurger', zodat die 2e call niet nodig is; dit eventueel in relatie tot het andere item over de Zaakdetails en de Zaakdocumenten van een verzameling zaken). - Huidige (tussen)situatie: Voor alles waar de standaard niets over zegt, kan uit StUF-ZKN geput worden, waarbij ik hoop dat we deze situaties elke keer zo goed mogelijk direct in ZSDMS kunnen opnemen. Zo voorkomen we dat al te uitgebreide implementaties nodig zijn voor leveranciers, die niet volledig StUF-ZKN ondersteunen, alleen maar 'tijdelijk'de huidige situatie willen werkend maken.
Ik meen begrepen te hebben dat deze functionaliteit op de lijst staat voor een volgende versie van de prefill services. Op zich wat lastig omdat de schema's van die services nu zijn opgenomen in een subfolder onder StUF-BG. Ik zou me ook voor kunnen stellen dat we een operatie geefLijstZaken toevoegen waarin (onder meer) de BSN van de initiator in de scope kan worden opgenomen.
Roel, een dergelijk item staat bij Prefill services op een lijst van items die 'bedacht zijn maar niet voor een specifieke versie ingepland zijn'. Dus het is niet zo dat deze op korte termijn op stapel staan. Ik ben er persoonlijk geen voorstander van om (op dit moment) zaakservices aan de prefill standaard toe te voegen; er komt een bijeenkomst die zich meer richt op het uitbreiden van de prefill services naar een gegevensmagazijn koppelvlak en die beweging werd breed gedragen in de aanwezigen van de betreffende werkgroep. Ik heb dan liever dat de suggestie in dit topic in de Zaak- en Documentservices erbij komt, zodat de E-formulieren zich als Zaakserviceconsumer binnen deze standaard (kunnen) gaan gedragen. Dat is volgens mij de meest zuivere variant. De suggestie om een operatie geefLijstZaken toe te voegen (met als mogelijkheid de BSN van de initiator in de scope) vind ik een goede. Dennis (en andere lezers), wat vinden jullie daarvan? (item geregistreerd als ZDS-37)
Joost, ik vind het een goed voorstel om een operatie 'geefLijstZaken' toe te voegen. Let wel dat het niet alleen mogelijk moet zijn om op een BSN deze vraag te stellen. Wat mij betreft stel je een vraag op postcode/huisnummer van de initiator (slechts een voorbeeld). We moeten dit in mijn ogen niet beperken.
De eerste uitbreiding van de prefill beperkt zich tot het RSGB. D.w.z. dat we gaan kijken welke relevante vragen je kunt stellen waarbij het antwoord bestaat uit gegevens die in het RSGB zijn beschreven. (Kijk voor een actuele situatie hier: https://new.kinggemeenten.nl/gemma/stuf/koppelvlakken/prs )
Het nieuwe discussieforum voor het koppelvlak PRS staat hier: https://vng-realisatie.github.io/StUF-Standaarden/discussie/gemma/koppelvlak-prs
@Jan: betekent dit dat een functionaliteit als geefZaakDetails niet binnen de huidige scope van RSGB bevragingen gaat vallen en we dus het beste de richting op kunnen die Joost al schetste? Nl. deze functionaliteit onderbrengen in de Zaak- Documentservices?
Op de teleconferentie van 12-02-2015 is besloten een nieuwe operatie met bijbehorend bericht te maken. Hiervoor wordt ook gekeken naar een vorig jaar gemaakte inventarisatie van welke berichten er wenselijk zouden zijn. Deze inventarisatie is te vinden op https://vng-realisatie.github.io/StUF-Standaarden/discussie/gemma/koppelvlakken-zs-dms/zaakbevragingen
Ik ben bezig een voorstel te maken en loop tegen de volgende vragen aan:
Dan zou een standaard zakLv01 vraagbericht gebruikt moeten worden. De zoeksleutels kunnen dan meegegeven worden in de zakVraagBody/gelijk, zakVraagBody/vanaf en/of zakVraagBody/totEnMet.
Als resultaat komt dan een lijst met zaak id's. Met deze id's kan dan via de GeefZaakDetails service meer informatie opgehaald worden.
Het enige waar ik dan nog mee zit is: in een koppelvlak moeten zaken juist helder en testbaar beschreven worden. Wanneer er geen duidelijke beperkingen zijn in wat kan/niet kan is dit niet SMART te definiëren.
Wat zijn de gewenste zoeksleutels? Of kunnen we deze niet vastleggen? Moeten we in dat geval deze service wel in het koppelvlak opnemen?