Gemeenten moeten zo snel mogelijk de term ‘fraude’ uit ICT-systemen verwijderen als deze term gekoppeld is of gekoppeld kan worden aan een persoon in het kader van de Participatiewet. Dat maakte de Vereniging Nederlandse Gemeenten onlangs bekend. Die term gebruiken voor enkel schenden van de informatieplicht is onnodig en dus onrechtmatig, aldus de Rechtbank Rotterdam.
We hebben het hier al vaker gehad over de kwalificatie van ‘fraude’ bij bijstandszaken. Iedere schending van een plicht van burgers wordt met die term aangeduid, hoewel strafrechtjuristen een héél wat specifiekere betekenis er aan toekennen. Bij gemeenten gaat dat zo:
Ten aanzien van de vermelding van fraude met betrekking tot het “verzwijgen van witte inkomsten” stelt verweerder zich op het standpunt dat deze vermelding terecht is. In de besluiten uit 2018 is geconstateerd dat eiseres haar inlichtingenverplichting (artikel 17, eerste lid, van de Participatiewet) niet is nagekomen. Dit valt onder de noemer bestuursrechtelijke fraude, aldus verweerder.Het ging hier om bedragen van € 194,26 en € 21,84, inkomsten uit arbeid die de burger volgens verweerder niet tijdig had doorgegeven. Daar is in 2018 over geoordeeld (met boete: € 92,28) en dat wordt dan geregistreerd onder het kopje “fraude: verzwijgen witte inkomsten” in De Computer.
De rechter kijkt hier kritisch naar, en hanteert daarbij de AVG als leidraad. Die eist immers noodzakelijkheid en het vereiste van minimale gegevensverwerking. Als je dan beseft dat fraude “in het normale spraakgebruik bedrog betekent en opzet veronderstelt”, en dat daar hier in het geheel niet van blijkt, dan is die term dus onrechtmatig.
Het zal dan best dat gemeentes dit intern “bestuursrechtelijke fraude” noemen. Sociale zekerheidsfraude is een ding, getuige deze OM-Aanwijzing, maar ook hier zit een element van opzet en misbruik in. Enkel iets niet opgeven is geen bewijs van opzet om te willen misbruiken.
De kwalificatie “fraude” moet dus worden verwijderd. De op zich juiste vermelding “verzwijgen witte inkomsten” mag blijven staan. Dit is een ding voor de ict-mensen, omdat kwalificaties als deze vaak geïmplementeerd worden als veldnamen, namen van tabbladen of tabelcodes en simpele stervelingen die niet kunnen aanpassen.
Meelezende ict-architecten of informatiespecialisten: hebben jullie Een Mening over het gebruik van juridische kwalificaties als veldnamen of kolomkoppen?
Arnoud
‘Natuurlijk’ moeten de juiste termen gebruikt worden. Woorden hebben een betekenis, woorden kunnen richting geven aan de denkwijze van de gebruiker. “Fraudeur! Controleren!” of “Mogelijk is hier een aandachtspunt?”.
Maar daar hebben ict-architecten of informatiespecialisten niets mee van doen? De architecten etc moeten nadenken over dat termen zijn aan te passen, maar wat er staat is aan hun vakinhoudelijke collega’s.
Ander voorbeeld van zulk taalgebruik: datalek. Door gebruik van die term denken velen alleen aan data die bij hackers terecht komt.
Veldnamen moeten net als variabelen duidelijk zijn welke data de velden bevatten, leesbaar zijn (dus niet te cryptisch en alleen gangbare afkortingen) en niet te lang zijn.
Alleen zie ik niet waarom de gebruiker ooit de veldnamen te zien zou krijgen. De sleutel is i18n, maak resourcebestanden met display strings voor alle veldnamen die je aan de gebruiker moet tonen of in documenten moet tonen.
Als je het goed hebt gedaan dan hoef je niet eens een nieuwe versie van de software op te leveren om het woord fraude in iets anders te wijzigen, je edit alleen een resource bestand.
Het maakt geen fluit uit of de variabele in de code nog het woordje fraude bevat, omdat niemand dat ooit te zien krijgt. Als je je er echt aan stoort kan je dat een keer oplossen als je toch met dat onderdeel bezig bent, maar waarom zou je als het werkt?
Als dat veld alleen wordt gebruikt om op het scherm te tonen prima. Maar vlagje1 met nu label “verzwijgen witte inkomsten” staat nog steeds in die query zoek alle mensen met vlagje1 en gaat nog steeds naar de “fraude” afdeling. Dus je moet veel meer doen dan alleen resource bestand aanpassen
Ga je er dan vanuit dat er kale database queries verstuurt worden naar de andere afdeling in plaats van rapporten, of dat de andere afdeling hun eigen software heeft die dezelfde database bevraagt?
Mijn ervaring is dat een gebruiker die software in een bepaalde taal instelt ook zijn uitvoer in die taal wil hebben. Daar waar de tekst op het scherm in documenten kwam (word, excel) gebruikte ik net zo goed de display string.
Als je kale queries gebruikt dan mis je een stap in je automatisering.
Een applicatie zal rapporten genereren maar er zal ook zo maar een scherm fraudeurs kunnen zijn. En op het scherm van de betreffende personen kan ook zo maar een vlaggetje “KIJK UIT!” zijn dat op basis van een query aan of uit gaat waarin een subset van dat meegewogen zal worden waar in veld12 meegepakt wordt.
Je zal overal waar dat veld direct of indirect gebruikt wordt moeten kijken want niet elk veld wordt 1:1 getoond.
En dit is geen taal instelling maar een fundamentele verandering in betekenis van het veld.
Over het algemeen is het handig om kolom namen te gebruiken die wat zeggen over wat er in de kolom te vinden is zeker als het op veel plekken gebruikt wordt. Maar als het dan een andere naam krijgt en dus ook ander betekenis dan kan dat een hoop gesleutel opleveren. Je kunt dan ook de data en de naam los koppelen vlag1 en dan een vertaal tabel vlag1 = label dan kun je “fraude” vervangen door “verzwijgen witte inkomsten”
Alleen gebruik je vlag1 ook wellicht in berekeningen of programma keuzes dus je moet dan toch ook weer in de code gaan sleutelen.
Probleem is niet het naampje maar de betekenis van dat veld. Je zult hoe dan ook moeten gaan sleutelen.
Dat is ook denk ik het grote probleem in de overheidssoftware wetten veranderen, organisatie van de overheid veranderd en al die software moet maar mee bewegen.
Ik snap wat je bedoelt als je een boolean veld hebt ‘bestuursrechtelijke fraude’ dan wil je dat veld in je software aanpassen als het geen fraude is. En dat kan in de praktijk voorkomen.
Maar als je veld een meer beschrijvende naam heeft (er zijn meerdere soorten van drie fraude dus dat zou ik wel verwachten), bijvoorbeeld ‘fraude verzwijgen witte inkomsten’ dan is het niet het meest urgente om dat aan te passen. Dan pas je de resource string aan naar ‘verzwijgen witte inkomsten’ om zo snel mogelijk aan de wet te voldoenen plan je een refactor in een later sprint/release.
Voordeel van i18n is niet alleen vertalingen, maar ook dat je geen hele nieuwe releases hoeft te doen om een taalvaut te verbeteren of dit soort wijzigingen door te voeren. Vereiste is natuurlijk wel dat je consequent de resource gebruikt in uitvoer en nergens de variabele-/veldnaam.
Het heeft mij in de praktijk een hoop werk bespaard dat ik vanaf inceptie van een groot project i18n heb gebruikt. Ondanks dat meedere talen geen vereiste was.
Ik heb jarenlang gewerkt aan een applicatie waar uitkeringen mee worden verstrekt. Op geen enkele manier werd daar ooit in de software of beschrijvingen het woord fraude gebruikt. Soms wel in een wijzigingsverzoek of analyse en dan heeft het meestal betrekking op het voorkomen of detecteren van echte fraude (bijvoorbeeld een medewerker die onrechtmatig geld uitkeert aan familie)
Wel bevat de software en beschrijvingen van het systeem termen als boete of maatregel of schorsing omdat deze zaken van toepassing kunnen zijn op een uitkering Bij werkgevers worden bovendien soms termen als faillissement of surseance gebruikt omdat deze relevant zijn bij betalingen aan werkgevers.
Ook heel gevoelig in uitkeringssystemen zijn zaken met betrekking tot detentie. Maar omdat dit een wettelijke uitsluitingsgrond kan zijn is vermelding vaak onvermijdelijk.
Wat ik uit de tekst en het vonnis haal is dat het woord “fraude” in een tekstveld is terecht gekomen, mogelijk door handmatige invoer of omdat het zo in een keuzemenu stond. Lering: Kijk goed naar alle “standaardwaardes” en pas deze waar nodig nodig aan. En instrueer alle medewerkers om het woord fraude alleen te gebruiken wanneer er strafrechtelijk gezien sprake is van fraude en dat bij administratieve sancties niet altijd sprake hoeft te zijn van fraude.
De instructie (of inrichting) zou zo moeten zijn dat wettelijk gedefinieerde termen niet buiten die definitie worden gebruikt zonder aan te geven dat een andere context gebruikt moet worden. Beetje hygiëne op informatieniveau kan geen kwaad.
Het is jammer dat deze blog niet verder is in gegaan op de bovenstaande quote. Mogelijk kan Arnoud hier een apart blog van maken. Immers laat dit zien dat het een mogelijke verder impact heeft dan men zo zou kunnen denken.
Wat voor verstrekkende implicatie zie je hier? Voor mij is het vanzelfsprekend dat “Wim is een fraudeur” een persoonsgegeven is. Hoe de gemeente er bij zou komen dat dit niet het geval is, ontgaat mij ten enenmale.
Ik moet onbedoeld denken aan het verhaal dat de politie eind vorige eeuw schoenmaat 99 registreerden als ze Marokkaan bedoelden. Ik weet niet of het waar is (en of de politie überhaupt schoenmaten registreren (waarom zouden ze?). Ras was geen veld, dus los je het maar anders op. Daar kan IT weinig aan/tegen doen…
Zou dit ook met terugwerkende kracht gerepareerd/terug gedraaid moeten worden voor alle gevallen van “
fraude:verzwijgen witte inkomsten” die bij de gemeente bekend zijn?Voor oudere zaken weet je in principe niet meer of er sprake was van “fraude: verzwijgen witte inkomsten” of alleen “verzwijgen witte inkomsten”, aangezien beide uitkomsten in hetzelfde veld weggeschreven werden.
Dit zijn geen veldnamen/kolomkoppen, da’s (als IT’er) een simpele patch op je eigen systemen.
Dit is veel breder; dit is een publiek gedeelde en zeer ambtelijk gecureerde taxonomie van feitcodes ( Gegevensregister SUWI).
Dus dit wordt nog interessant misschien: Immers, feitelijk is het enige opgeslagen persoonsgegeven “Er was een feitcode 54 melding over Wim”.
De gestandariseerde omschrijving van 54 is “fraude: onjuiste opgave woonadres”. Noch IT’ers noch ambtenaren kunnen anders kiezen, het zijn geen twee delen.
Anders gezegd, als “fraude” in die omschrijving niet meer mag, kan geen enkele instelling op dit moment nog meldingen met code 54 (of alle andere “fraude: ” codes) maken voor onjuiste adresgegevens tot die omschrijving in die taxonomie aangepast is en iedereen patches voor z’n systemen heeft geschreven en toegepast.
Het leidt bovendien tot de paradoxale conclusie dat een presentatie-labeltje op feitelijkheid gecorrigeerd moet worden, terwijl er voor de burgers netto niets aan de hoeveelheid persoonsgegevens in het systeem verandert.
Zeker wel, aangezien fraude impliceert dat het strafrechtelijke (dus bijzondere) persoonsgegevens zijn. Bovendien gaat de impact veel verder. Een beoordelend ambtenaar dat in de geschiedenis van de uitkeringontvanger ‘fraude’ ziet staan, heeft meteen een veel sterkere bias, dan de ambtenaar die ‘verzwijgen inkomsten’ ziet staan. Dat heeft direct effect op hoe een nieuwe fout wordt beoordeeld.
Na het waden door 1255 pagina’s gegevensbeschrijving (Wat heeft een “Wielbasis voertuig” (p. 1251) te maken met uitkeringen?) is mij wederom duidelijk waarom automatisering bij de overheid duurder is dan nodig, langer duurt dan nodig en als het eenmaal opgeleverd is niet lekker werkt.
Ja, de rechter heeft dit document afgekeurd. Ik hoop dat het fixen van dit probleem nog onder de garantie valt.
Als ICT’er heb ik wel degelijk een mening over dit soort systemen, maar uiteindelijk zal ik, als er gebouwd moet worden, moeten voldoen aan de eisen die de opdrachtgever (en werkgever) er aan geeft. Als ik die eisten te dol vind, dan zal ik er wat van zeggen, en eventueel vragen om een en ander nogmaals te laten bekijken door de interne jurist, en daarbij even behulpzaam wijzen naar wetsartikelen of uitspraken zoals deze, maar als daarna de werkgever volhardt, en zegt, ach dat loopt zo’n vaart niet, of, volgens onze interne jurist is alles prima in orde, dan kan ik eigenlijk maar twee dingen doen: ontslag nemen of het implementeren zoals gevraagd (waarbij ik er dan wel even zorg dat er een kopie van het advies van de interne jurist of de opdracht in het persoonlijke archief zit, zodat ik altijd kan aantonen: ja daar hebben jullie echt om gevraagd). Gelukkig heb ik dat de laatste tijd niet aan het handje gehad, al is het wel zo dat ik af en toe kromme tenen krijg van wat de overheid allemaal aan informatie verlangt van banken.