Vanuit de invoering van de participatiewet en rondom afvalstoffenheffing is er behoefte vanuit verschillende applicaties om het aantal bewoners op een adres te kunnen volgen. Mocht het aantal wijzigen (op basis van een GBA-gebeurtenis) dan wil een applicatie hiervan op de hoogte gebracht worden (via een distributiesysteem). Momenteel biedt het informatiemodel RSGB hier direct geen ondersteuning voor, wel kan het via een omweg nu worden gerealiseerd door de afleiding van het aantal bewoners in de taakspecifieke applicaties zelf te doen. Dit is mogelijk als de betreffende personen en hun verblijfsadressen worden gevolgd. Dit lijkt niet efficiënt en daarom lijkt het goed om hiervoor een voorziening te treffen, voordat er extra elementen worden bedacht door verschillende leveranciers.
do, 29-01-2015 - 10.34u
#1
Aantal bewoners op adres
Als aanvulling: in bepaalde situaties (bv afvalstoffenheffing) is alleen het aantal bewoners op een peildatum interessant en is niet van belang (ook vanwege privacy) welke personen dit zijn, terwijl in andere situaties (bv kostendelersnorm) wel van belang is te weten wie op het adres ingeschreven zijn.
Dit soort gegevens nemen we niet op in het informatiemodel. Deze informatiebehoefte heb ik doorgegeven aan de werkgroep RSGB bevragingen .
Ik ben benieuwd hoe je die efficiëntere voorziening voor ogen ziet en op welke wijze we die eventueel zouden kunnen meenemen in de werkgroep RSGB-bevragingen. Jouw ideeën daarover kan je bij mij aanleveren en dan zorg ik dat ze besproken worden in de werkgroep RSGB-bevragingen.
Overigens, vooralsnog lijkt mij de door jou beschreven omweg de juiste wijze om hier mee om te gaan. Opgevraagde gegevens worden dan door de taakspecifieke applicaties omgezet in de benodigde informatie.
Dennis schrijft: "Dit is mogelijk als de betreffende personen en hun verblijfsadressen worden gevolgd" maar feitelijk werkt dit niet omdat je alle personen moet volgen om te weten wanneer een van hen zich vestigt op een adres waarvan je het aantal inwoners wilt bijhouden. Zeker vanuit privacy oogpunt is dit ongewenst.
Ellen stelt: "Dit soort gegevens nemen we niet op in het informatiemodel" maar dat vind ik niet terecht omdat binnen het informatiemodel beschreven moet worden (of tenminste hieruit afleidbaar moet zijn) op welke wijze een praktische informatiebehoefte kan worden geïmplementeerd.
Deze behoefte bestaat er uit om geïnformeerd te worden over wijzigingen in de bewonerssituatie op een bepaald adres. De bewoners situatie wordt bepaald door vestigingen, vertrekken, geboortes etc. Deze gebeurtenissen worden getriggerd door wijzigingen in de gegevens van een persoon terwijl de informatiebehoefte ligt in de gegevens van een adres (het aantal bewoners). Het probleem ligt naar mijn mening in het feit dat de bijhouding van gegevens over de relatie tussen twee objecten binnen StUF sectormodellen niet bi-directioneel is (een wijziging van het adres van een persoon kan niet worden ontvangen als een wijziging van de personen die verblijven op een adres). Dit laatste is een bewuste keuze binnen de StUF sectormodellen omdat het afwijken hiervan andere problemen voor de consistente bijhouding van gegevens kan opleveren. Toch moeten we zoeken naar een mechanisme dat voorziet in de behoefte.
@Johan: Het gaat hierbij dus niet om bevragingen (re-actief), maar om notificaties (pro-actief).
Vanuit verschillende processen zal er behoefte zijn aan informatie over hoeveel, of welke, inwoners bekend zijn in relatie tot een verblijfseenheid. Dat zou je ook uit een gegevenspakhuis kunnen halen. Blijft echter wel een bevraging. Vraag is dus wanneer je die bevraging moet gaan doen, welke trigger gebruik je daarvoor. En zou je "triggers" in kunnen zetten om bevragingen automatisch te doen en het resultaat ergens afleveren.
Opnemen in het RSGB lijkt mij lastig. Het model moet wel de mogelijkheid bieden om diverse vragen te stellen (bijvoorbeeld aantal bewoners in een straat of pand, aantal bedrijven in een gemeente of aantal verhuizingen in een periode).
Er zijn hier een aantal zaken aan de orde.
Opnemen in het RSGB of niet?
In het RSGB modelleer je die _gegevens_ die je minimaal moet registreren om maximaal informatie af te leiden. (Zo registreer je niet hoe oud iemand is, maar op welke dag dat hij geboren is). Zo'n gegeven moet je dan ook 1-maal registreren. Hoe het in de StUF-Berichten voorkomt (de opmerking van John) is daarbij nog niet relevant.
Opnemen als antwoord op een vraag binnen het RSGB?
In de derde sessie van de werkgroep RSGB-bevragingen hebben we al geconcludeerd dat het afleiden van gegevens (op basis van geregistreerde) gegevens tot het gegevensmagazijn kunnen behoren als er geen sectorspecifieke regels voor nodig zijn. Als "het aantal bewoners op adres A op moment M" puur een telling is van de natuurlijke personen waarbij het woonadres gelijk is aan A voor het moment M. Dan lijkt me dat dit attribuut toegevoegd kan worden aan de bevraging die gegevens over een adres oplevert.
Sturen van een trigger als het aantal bewoners op een adres verandert?
Dit is inderdaad geen onderdeel van RSGB-bevragingen zoals Johan stelt. Dit vergt een 'abonneringsfunctionaliteit' op het gegevensmagazijn. In die functie kun je dan eerst aangeven op welke wijzigingen je je wilt abonneren. En dat kunnen in principe wijzigingen zijn in geregistreerde gegevens, maar ook in afgeleide gegevens. Je kunt je dan bijvoorbeeld ook een signaal laten sturen als iemand 18 is geworden. Vervolgens kun je voor elk signaal ook nog aangeven a) welke gegevens je bij dat signaal wilt hebben (bijvoorbeeld alleen het BSN of alleen het Adres-ID, maar het kan ook zijn dat je er meer gegevens direct bij levert) b) wanneer je het stuurt (direct bij veranderen, aan het eind van de dag, aan het eind van de week). Ook daar zou je 'generieke functionaliteit' om heen kunnen definiëren, maar dat lijkt me een koppelvlak op zich.
@Theo: binnen welke (werk)groep / gremia wordt dit nu verder uitgewerkt?