Enkele Belgische burgers zien persoonsgegevens naamgenoot bij belastingaangifte

Enkele Belgische burgers hebben persoonsgegevens van andere personen met exact dezelfde naam kunnen inzien via het belastingportaal Tax-on-web. De Federale Overheidsdienst Financiën heeft het datalek erkend en het probleem zou inmiddels verholpen zijn.

Een van de getroffenen zegt tegen het radioprogramma De Inspecteur dat ze onder meer het huwelijkscontract en documenten over eigendommen van een naamgenoot kon zien via de officiële belastingaangiftewebsite, zo meldt VRT. Nadat het incident gemeld werd bij de FOD Financiën zou het nog acht maanden geduurd hebben voordat het datalek verholpen werd. Een andere getroffene meldt dat haar dochter en schoonzus dezelfde naam hebben; bijlagen van deze twee personen werden op Tax-on-web verwisseld.

De Federale Overheidsdienst Financiën zegt: "Mensen krijgen gegevens te zien van anderen en dat is niet de bedoeling. De oorzaak is dat nog niet alle diensten het rijksregisternummer gebruiken als ze documenten doorgeven aan ons. Dat rijksregisternummer is een uniek nummer voor elke inwoner in ons land. Maar als documenten alleen een naam vermelden, kan er een naamsverwarring zijn. Als het rijksregisternummer erbij staat, kan dat in principe niet."

Bij bepaalde overheidsdiensten wordt er in België dus nog geen gebruik gemaakt van een rijksregisternummer. Dit zou vooral gelden voor kleinere instanties. In deze gevallen worden documenten dan nog op basis van de naam van een persoon ingevoerd, waardoor het in de bovenstaande gevallen klaarblijkelijk misging.

Reacties (79)

[SinergyX]

Even los van overheid, bedrijven, directie, contracten, welke enigzins geschoolde programmeur haalt zoiets in z'n hoofd? Ik werk met relatief kleine projecten, maar zelfs in een team van 4 man als er maar 1 iets 'schrijft', ik heb geen bijzonder 'grote' programmeerachtergrond, maar zulke dingen kan ik zelfs bedenken.

Natuurlijk, je weet het pas als het voorkomt, ik heb altijd dezelfde naam als mijn vader gedragen dus ik was er bekend mee, maar welke 'mindset' moet zo'n programmeur dan hebben om zoiets te schrijven? Zelfs als er een kneus van 'projectowner' bovenhangt die 0,0 kennis heeft van programmeren, dan kan je toch daar iets over zeggen? Typefoutjes, select *.*, where 'id' = "", dat gebeurd.. maar dit is niet anders te bedenken dan 'by design'.

Bedoel:

Smals beschikt over een indrukwekkend team van 8 onderzoekers met een sterke academische achtergrond, meestal op doctoraatsniveau, dat ter beschikking staat van individuele klanten.

Maar geen kennis heeft van basisprogrammeren en databases?

[Reactie gewijzigd door SinergyX op 22 juli 2024 15:57]

[TheFoundation101]

Ik weet niet goed waarom je verwijst naar Smals. Die werken niet voor het ministerie van Financiën, die doen alleen de IT voor de sociale zekerheid (RSZ, RVA, RIZIV, ...). En die gebruiken gegarandeerd het rijksregister als authentieke bron voor voor al hun projecten, en steken alle authenticatie achter de FAS / CSAM.

Het overgrote merendeel van zulke persoonsverwisselingen zijn het gevolg van menselijke fouten bij invoer van gegevens vanop papier. Als een loketbediende bij de gemeente een document koppelt aan de verkeerde persoon, is het kwaad geschied. En dat gebeurt vaker dan je denkt, zeker in kleinere gemeentes waar nog veel op papier verloopt, de loketbedienden constant bibberig ingevulde papieren formulieren van bijziende oudjes moeten overtypen, en er geen noemenswaardig IT budget is.

[Reactie gewijzigd door TheFoundation101 op 22 juli 2024 15:57]

[pieterdebie]

Enkele aanvullingen:

Smals werkt zeker niet enkel voor de sociale zekerheid. De FOD financiën is lid en kan dus beroep doen op Smals, maar Tax-On-Web is géén product van Smals.

Voor anomalieën in data zoals jij omschrijft is er bij Smals een systeem opgezet om deze te voorkomen, corrigeren en de bron van het probleem te identificeren en aan te pakken.

Maar geen kennis heeft van basisprogrammeren en databases?

Zowel analysten (simpelweg: de personen tussen produceigenaar en developers) als developers hebben zeker die kennis

Disclaimer: ik ben dev bij Smals.

[redfox314]

Ik hoop dat er idd wat verbetering zit voor nieuwe ontwikkeling want het sftp systeem van social security is om te huilen om mee te integreren. Amper test omgevingen, degene die er is, is een andere folder op dezelfde (productie) server. Volgt regelmatig zelf het gemaakte protocol niet. Geen deftige feedback bij fouten.

[Oon]

Dit probleem heeft dus totaal niks te maken met programmeren of databases, maar met data die is aangeleverd zonder persoonsnummer.

[cadsite]

Als je een systeem op poten zet dan moet je er voor zorgen dat enkel volledige data aanvaard wordt.
Nog even en we aanvaarden Jo**** als username.

[TheFoundation101]

Dat is het ideaal. Daarnaast is er nog de echte wereld.

Waarin mensen soms geen papieren hebben. Of hun identiteitskaart is gestolen. Of hun dossiers gingen verloren in een brand of overstroming. Of ze zijn hulpbehoevend en kunnen zich niet uitdrukken. Of het zijn toeristen met enkel een paspoort. Of het zijn rondtrekkenden zonder vast adres. Of ze hebben nooit kunnen/willen voldoen aan bepaalde wettelijke verplichtingen om hun gegevens bij te werken (faillissement, overlijden). Of ze spellen hun eigen emailadres verkeerd op een formulier.

Onvolledige gegevens zijn een realiteit in elke overheidsdatabank. Tenzij men papier afschaft en iedereen verplicht om digitaal te gaan, gaat dat ook de realiteit blijven in de 21e eeuw.

[Remzi1993]

Dan zorg je ervoor dat je meerdere identifiers gebruikt zoals geboortedatum en geboorteplaats. Dan is het bijna onmogelijk om twee mensen met precies dezelfde naam te verwarren.

[Superbra]

Ik heb dus echt wel situaties meegemaakt waarbij van iemand de echte geboortedatum/geboorteplaats niet bekend was. Ik heb persoonlijk verschillende personen ontmoet (beroepsmatig, bank) waarvan enkel geweten was dat ze in een specifiek land geboren waren en dat ze 'ongeveer' een leeftijd hadden. Op officiële documenten van dat land!

En dan werden die dus geregistreerd als geboren op 1/1/1960 of 11/11/1973 in de hoofdstad van dat land.

Welkom in de echte wereld. Van dergelijke mensen kan je dus echt onmogelijk exacte gegevens bekomen. En in een andere databank worden dan misschien andere gegevens ingevoerd...

[Remzi1993]

Dat is inderdaad heel vreemd. Hebben die mensen geen paspoort? Als instelling zou ik dat wel eisen alvorens zaken met ze te doen.

[Superbra]

Oh, die mensen hebben wel degelijk een paspoort. Maar die kwamen uit afrikaanse landen waar de administratie het niet zo nauw nam. Die mensen wisten zelf niet waar en wanneer ze geboren waren. Enkel hoe oud ze ongeveer waren.
Ik spreek nu wel van ervaringen van 30 à 40 jaar geleden. Ik mag hopen dat de toestand ondertussen verbeterd is, maar die specifieke personen gaan nooit hun exacte geboortedatum kennen.

Mijn hele punt was dat wij als informatici wel kunnen dromen van een perfecte database maar dat die in realiteit, vaak door menselijke fouten, niet zo perfect is. En dat je, hoezeer je ook je best doet, altijd één of ander geval zal missen in al je qualitychecks.

[Remzi1993]

Mee eens. Dat is inderdaad een probleem waar we rekening mee moeten houden.

[Hyronymus]

Ik denk dat iedereen het kan bedenken, heel veel mensen het aangeven als aandachtspunt en heel weinig mensen controleren of het toegepast is.

[Aaargh!]

“Smals beschikt over een indrukwekkend team van 8 onderzoekers met een sterke academische achtergrond, meestal op doctoraatsniveau, dat ter beschikking staat van individuele klanten.”

Maar geen kennis heeft van basisprogrammeren en databases?

Mijn ervaring met academici is dat je dat soort mensen idd geen productiecode moet laten schrijven. Vaak weten ze alles van de theoretische achtergrond maar dat is iets heel anders dan productiecode schrijven.

[Gamebuster]

Precies! Iedereen weet dat je moet matchen op volledige naam EN geboortedatum. Niemand is met dezelfde naam geboren op dezelfde dag.

/s

[Reactie gewijzigd door Gamebuster op 22 juli 2024 15:57]

[jongetje]

Dat is een dikke aanname, waarbij er vast een geval zal zijn waarbij dat wel zo is.

[Gamebuster]

Vandaar mijn /s die je misschien net gemist hebt.

[Bruin Poeper]

Vandaar mijn /s die je misschien net gemist hebt.

Wat betekent /s dan?

[Christoxz]

/sarcasme

[Bruin Poeper]

/sarcasme

Altijd leuk om vreemde volken en culturen te leren kennen

[jpsch]

Daar kun je nooit vanuit gaan. Kans is klein, maar niet uit te sluiten.

[CH4OS]

Waarom moet het probleem gelijk bij de programmeur liggen?

De oorzaak is dat nog niet alle diensten het rijksregisternummer gebruiken als ze documenten doorgeven aan ons. Dat rijksregisternummer is een uniek nummer voor elke inwoner in ons land. Maar als documenten alleen een naam vermelden, kan er een naamsverwarring zijn.

Lijkt mij dus dat de oorzaak bij die partijen ligt die (nog) niet het rijksregisternummer gebruiken.

Schijnbaar is niet voor alle documenten het rijksregisternummer er aan gekoppeld van de persoon in kwestie. Vervolgens moet er ergens anders mee een match gemaakt worden. Schijnbaar is dan alleen de naam een optie. Gelijk het probleem in de schoenen van de programmeur schuiven, terwijl er nu een dieper iets is waardoor dit kan gebeuren, is echt te kort door de bocht.

[Reactie gewijzigd door CH4OS op 22 juli 2024 15:57]

[SinergyX]

Omdat het simpelweg geschreven is, ik kan je duizend documenten aanleveren die werkelijk nergens op slaan, in dat geval zeg jij simpel 'kan niet, gaat niet, lukt niet, hoort niet'. Maar nee, je gaat werkelijk met gezond verstand als nog doodleuk typen 'where name = fikkie'.

Alsof ik een monteur vraag om de gasleiding aan de waterleiding aan te sluiten, dan heb ik maar 1 pijp door m'n huis lopen, dan maar gewoon doen 'want het werd mij opgedragen?'

[CH4OS]

Dat is wel een aanname natuurlijk. Je weet niet hoe en of er andere manieren zijn om te zorgen dat er wel de juiste documenten bij de juiste personen terecht komen. Dat het ook al opgelost is kan best zijn doordat die andere partijen nu wel het rijksregisternummer gebruiken, bijvoorbeeld. Ik blijf het te kort door de bocht vinden om de programmeur de schuld te geven.

Edit: CC @Anoniem: 454358

[Reactie gewijzigd door CH4OS op 22 juli 2024 15:57]

[Cybergamer]

Ik niet. Je zorgt ervoor dat je een uniek iets hebt, in dit geval het rijksregister nummer, die verplicht is in te vullen. Heb je die niet? Jammer dan!

Hoe moeilijk is dat om dat te bedenken?

[Ayiko]

Of de programmeur toont een keuzelijst op basis van de naam aan een ambtenaar van Financiën met de vraag of het document aan 1 van deze personen gelinkt kan worden, of indien niet, om een andere persoon op te zoeken en in te geven. De ambtenaar kiest vervolgens de verkeerde persoon, diens rijksregisternummer wordt eraan gekoppeld en het kwaad is geschied.
De vraag blijft dus, ziet de "juiste" persoon ook zijn documenten, net zoals de verkeerde? Dan riskeert het echt een (ontoelaatbaar) select * where name = '...' te zijn. Als enkel de verkeerde persoon die documenten nog ziet, dan heeft een werknemer waarschijnlijk zelf de misse persoon gekozen en hangt het document nu (met rijksregisternr) aan die misse persoon.

Wij krijgen aanvraagformulieren binnen, zeer regelmatig is het rijksregisternummer niet ingevuld of verkeerd. Soms een nummer van een identiteitskaart, soms hun gsmnummer. Als we met de andere gegevens wel duidelijk de persoon kunnen identificeren, gaan we hun aanvraag niet gaan weigeren.

Volgens de wet mogen we eigenlijk enkel nog het insz vragen, alle andere gegevens kunnen we opzoeken bij de KSZ. Dit streven om de gebruiker niet nodeloos telkens zijn naam, adres, geboortedatum, etc te laten opgeven is nobel, maar als het opgeschreven nummer verkeerd is, heb je geen enkele manier om te vinden wie het was of naar wie je het moet terugsturen ter verbetering.

[Cybergamer]

Wij krijgen aanvraagformulieren binnen, zeer regelmatig is het rijksregisternummer niet ingevuld of verkeerd. Soms een nummer van een identiteitskaart, soms hun gsmnummer. Als we met de andere gegevens wel duidelijk de persoon kunnen identificeren, gaan we hun aanvraag niet gaan weigeren.

En daar gaat het dus al fout.

[Ayiko]

Je bedoelt dat we iemands uitkering/terugbetaling zouden moeten weigeren omdat die een of ander arbitrair gegeven nummer van 11 cijfers niet weet of er een foutje in gemaakt heeft? Dat is nogal hardvochtig, en als die persoon in beroep gaat, dan gaan we dat zeker verliezen.

Er zijn regels opgesteld ivm vereisten voor een geldige aanvraag. Eenduidig identificeerbaar is er 1 van, en dat kan met een correcte naam, adres, geboortedatum, of met een geldig insz.
Enkel een naam zou niet mogen volstaan, dat zou meestal ook meerdere resultaten opleveren bij een opzoeking bij de KSZ en zonder andere gegevens niet voldoen aan de identificeerbaarheidseis..

[Wim Cossement]

Er zijn eigenlijk maar 5 cijfers die je moet onthouden. Dus als die persoon bijvoorbeeld een kopie/foto van beide kanten van zijn ID mee moet geven heb je dit probleem niet. En als die dat niet kan is dat zijn probleem, tegenwoordig heeft elke persoon, zelfs een bootvluchteling een GSM met camera.
Allez, als je een uitkering wil moet je of men toch in staat zijn die correct in te vullen voor jouw, niets met hardvochtigheid te maken.

[CH4OS]

Het punt is dus dat voor de aangiftes niet alle bedrijven dat gebruiken. Ik had zelf ook inderdaad een exception gegooid als er geen rijksregisternummer is. Maar er zal ongetwijfeld iets zijn waardoor dit er doorheen geglipt is. maar dat hoeft niet direct de fout van de programmeur te zijn, dat is mijn punt.

[Cybergamer]

Nee klopt, maar als programmeur zijnde zou ik dan wel zeggen dat er een probleem is. Ik snap sowieso niet hoe mensen het voor elkaar krijgen om een database op te zetten zonder unieke key.

[CH4OS]

Voor hetzelfde geld is dat dus gedaan en is de ontwikkelaar dus overruled door hogerhand, weten wij veel. Maar hier wordt wel de developer aangekeken als de boosdoener.

[loki504]

Je kan natuurlijk als programmeur niet je eigen regels gaan bedenken. Je kan hooguit aangeven dat het niet veilig is. En dan moet de overheid daar iets aan doen.

[Cybergamer]

Ja, diezelfde overheid die jouw gegevens 'veilig' bewaard (met een kleine mix van je naamgenoot). Sorry hoor, maar ik zie dat echt als een grove fout, en iemand moet er verantwoordelijk voor zijn.

[loki504]

Het is zeker een grove fout dat hoor je mij niet zeggen. En iemand is daar verantwoordelijk voor maar dat hoeft niet direct de programmeur te zijn.

[mjtdevries]

Een ieder die op basis van alleen een naam een match wil maken maakt een grove fout waarvoor ze verantwoordelijk gehouden zouden moeten worden.

En dan maakt het niet uit wat de functie is.
Wellicht dat mensen het een programmeur wat harder aanrekenen omdat een programmeur minstens het IQ moeten hebben om dit te snappen. Dit hoort bij het vak.
Dat kun je misschien niet van de andere ambtenaren zeggen die dit soort fouten maken.

[loki504]

Maar als jij naar je leidinggevende/projectmanager/ wie dan ook boven je staat en zegt hey dit dit en dit klopt niet daar daar en daarom en de andere zegt dan weten we is niet belangrijk etc dan is het niet de fout van de programmeur.

[mjtdevries]

Dat is makkelijk afschuiven. Je weet gewoon dat zoiets grote problemen gaat opleveren. (zoals nu dit datalek) Als je dan een manager hebt die zo ongelooflijk dom is dat ie dat niet belangrijk vind, dan heb je ook een verantwoordelijkheid om die manager te passeren, of een intern klokkenluider process te zoeken. Je laat zoiets niet mis gaan omdat die ene manager een sukkel is.

[loki504]

En wie zegt dat het nu niet gedaan is? We weten niet hoe dit intern tot stand is gekomen. En wat er wel of niet besproken is. Dan is roepen het is de schuld van de programmeur wel erg makkelijk

[mjtdevries]

Lees eens opnieuw wat ik geschreven heb. Ik zeg niet dat het alleen de schuld van de programmeur is.

Feit is dat nu dit datalek in het nieuws is gekomen. Dus blijkbaar is het niet voldoende geescaleerd, want dan was het niet gebeurd.

[Argantonis]

Dit is echt niet hoe het werkt. Denk eerder dat medewerkers gewoon op naam kunnen zoeken en daarbij dan een document waarop alleen een naam staat handmatig hebben gekoppeld aan een bepaald dossier via het zoekresultaat.

[Cid Highwind]

Zoiets gebeurt regelmatig en is ook niet aan België voorbehouden. Ik heb mensen uit de administratie (lees: uitgeschreven uit het land en sociale zekerheidssystemen) zien worden, simpelweg omdat de simpele ziel bij de gemeente enkel keek naar achternaam, geboortedatum en geboorteplaats en de eerste de beste nam zonder verdere check.

Had waarschijnlijk nog nooit van het concept tweelingen gehoord.

[Argantonis]

Precies, ik ben het met je eens. Dit zijn gewoon handmatige zoekacties op naam en dan handmatige koppelingen. Maar niet zoals de commenter waar ik op reageer suggereert dat het automatisch gebeurt en dat de code automatisch probeert documenten te matchen op achternaam.

[genosis]

Wie dan, de manager? Die maakt de code niet. Dit is echt absurd, ergens zit daar een query in die op naam zoekt, wat bizar is.

[Argantonis]

Zoals ik al ergens ook al zei, dit is echt niet hoe het werkt. Denk eerder dat medewerkers gewoon op naam kunnen zoeken en daarbij dan een document waarop alleen een naam staat handmatig hebben gekoppeld aan een bepaald dossier via het zoekresultaat.

[CH4OS]

Misschien de product owner, misschien de architect die de omgeving en applicatie ontworpen heeft? Er zal echt een reden zijn dat dit er tussendoor is geglipt en dat hoeft echt niet alleen maar de schuld te zijn van de programmeur.

[SunnieNL]

mmm.. ik zou op zo'n moment dan gewoon zeggen:
als geen rijksregistratienummer in document = reject request

Het dan koppelen aan een naam is echt een slechtere keuze dan bovenstaande.Waarom zou er ergens anders een match mee gemaakt moeten worden? Reject is ook een optie.
Beetje fail safe versus fail lucky tov rijksregistratienummer. In het laatste geval krijg je een privacy / GDPR probleem wat naar mijn idee erger is dan dat het document gewoon niet geaccepteerd wordt.

[CH4OS]

Ja, bijvoorbeeld. Dat had mijns inziens ook wel de veiligste optie geweest en dat het er niet was is dan ook wel bedenkelijk. Het dan op naam koppelen laat wel zien inderdaad dat dat niet het allerslimste idee is.

[Frame164]

Van een ontwikkelaar mogen we creatievere oplossingen verwachten. Domweg door programmeren terwijl je geeneens ITer hoeft te zijn om te snappen dat dit niet kan werken past dan wel weer in een veelvoorkomende respons van ITers dat het allemaal fout zit bij "het management".
Terug naar de techniek: er zijn genoeg manieren te bedenken om unieke resultaten te krijgen. Het is niet veel meer dan een uitgebreider if then else statement. Als je meerdere dezelfde namen terug krijgt ga je verder op basis van adres, geboortedatum etc.

[CH4OS]

Zeker mag dat, maar dat betekend niet dat een creatievere oplossing van die ontwikkelaar ook daadwerkelijk goed werkt voor de gevraagde oplossing. Daarop pas je toe wat het beste en veiligste werkt. Maar wat als dat er simpelweg niet is? Dan kan je als ontwikkelaar/software engineer wel allerlei andere hoepels bedenken waardoor het veiliger is, maar of dat ook werkbaar is? Uiteindelijk gaat het erom dat de documenten niet gekoppeld zijn aan een rijksregisternummer en bedrijven blijkbaar nog niet altijd ermee werken (om wat voor reden dan ook). De oplossing kan dan best zijn dat die bedrijven alsnog het rijksregisternummer is gaan gebruiken.

[b12e]

nuja dat zou dus werken met RRN en dan zou het prima zijn, dat nummer is in heel België uniek.

Maar als het op naam moet gelinkt worden, en je hebt niks anders, misschien een (Belgische) postcode.. waar ga je het dan tonen? bij je eerste, tweede of derde resultaat?

Het moet wel getoond worden, want het gaat om belastingen...

[Weicool]

En dat wordt straks nog vele malen erger als mensen overal hallucinerende generative AI gaan gebruiken!

[Vlizzjeffrey]

Je zou denken dat dit een situatie is waarvan van tevoren bekend is dat daar rekening mee gehouden moet worden, het is geen geheim dat er personen zijn met exact dezelfde naam, vreemd dat zoiets pas in 2023 aan het licht komt.

[Polderviking]

Ik heb een keer ergens een stuk gereedschap besteld die maar niet op kwam dagen.

Toen ik er eindelijk een keer achteraan belde en mailde kwam ik er achter dat er ergens anders iemand met exact dezelfde naam een keer iets niet had teruggestuurd en ze daarom mijn naam maar op de zwarte lijst hadden gedonderd. (alleen naam, geen NAW combi ofzo)
In de communicatie gingen ze ook gewoon zonder enige twijfel vanuit dat ik die persoon was en zo spraken ze me ook gewoon aan, ze waren volledig van plan mijn betaling te gijzelen.
Ook al woonde de persoon waar ze het geschil mee hadden in een ander land. (BE, ik ben NL)

Ik moest ook nog soort van mijn best doen ook om ze overtuigen dat er allicht meer personen zijn met mijn naam. Sommige mensen hebben een bizar wereldbeeld.

Dit is dan "maar" een webshop. Van overheid verwacht je meer. Maar toch.

[Reactie gewijzigd door Polderviking op 22 juli 2024 15:57]

[Shamalamadindon]

https://www.kalzumeus.com...mers-believe-about-names/

[CHeeCH]

Iets soortgelijks meegemaakt in Nederland ooit rond 2015-2016. Kreeg opeens declaraties van ziektekosten-verzekering (CZ) van een persoon met toevallig precies dezelfde voorletter/achternaam/geboortedatum/provincie combi als mij

Deze persoon maakte veel kosten die vervolgens van mijn eigen risico afgehaald werden. Moest toen zelfs bewijslast aanleveren om te bewijzen dat ik dit echt niet was (mijn werkgever kon gelukkig aantonen dat ik echt niet in een bepaalde apotheek was, op bepaalde tijdstippen). Heeft ook bijna 2 jaar geduurd en vele telefoontjes en brieven totdat het helemaal opgelost was.

Volgens CZ konden zij er niets aan doen want "het bedrijf die de daadwerkelijke declaraties afhandelde werkte met een ander systeem"

[Qwerty-273]

Alle oudere mensen kunnen de ophef in NL ten tijde van de invoering van het sofinummer misschien nog wel herinneren (die het fiscaal nummer opvolgde en zelf door het BSN werd opgevolgd). En ja voor die tijd was het heel normaal op alleen namen te gebruiken, vaak nog met de geboorte datum erbij voor de uniekheid. Ik snap dan ook niet dat men niet de juiste check heeft gedaan door ook naar de geboorte datum te kijken (al kan het zijn dat dit niet is vastgelegd en er dan is gekeken naar locatie).

Slordig, zeker aangezien het rijksregisternummer sinds midden jaren '80 bestaat. Wel nog een punt of elke organisatie in dit verhaal met het sectoriaal comité van het rijksregister heeft overlegd om dit nummer te mogen gebruiken.

[Anoniem: 1961754]

schokkend dat zoiets in 2023 nog voorkomt, en al helemaal bij overheden. Of misschien toch niet.

Zelfs op het MBO leer je dat je altijd moet werken met een unique identifier. Een persoonnaam kan en mag dat nooit zijn, zelfs niet in combinatie met geboortedatum. Dan op z'n minst nog een combi plus volgnummer.
Maar een overheidsdienst (hoe klein ook) die niet met een overheidsregistratienummer werkt verdient de faalhazenprijs.

Als ik dat zou moeten projecteren op Nederland, waar de overheden aan de slag moeten met de Digitaal Stelsel Omgevingswet (DSO) dan houd ik m'n hart vast als allerlei systemen aan elkaar gekoppeld moeten worden. Daar heb je namelijk niet alleen te maken met persoonsgegevens maar ook met kadastergegevens en weet ik veel wat voor andere systemen waarvan alle objecten uiteraard een UID dienen te hebben, ook in combinatie met andere databases.

In geval van grotere overheidsinstanties die datasets aangeleverd krijgen van kleinere instanties hadden die eerst aan de slag gemoeten met het correct koppelen aan de rijksregisternummers alvorens eea live te zetten in het betreffende systeem voor belastingaangifte.

Dit zijn pure beginnersfouten als je het mij vraagt, en ik ben niet eens programmeur.

[dasiro]

Bij bepaalde overheidsdiensten wordt er in België dus nog geen gebruik gemaakt van een rijksregisternummer.

Niet per sé, dit is een eigen interpretatie van

De oorzaak is dat nog niet alle diensten het rijksregisternummer gebruiken

De FOD financiën spreekt over "diensten" niet specifiek "overheidsdiensten", er zijn namelijk nog een hoop andere instanties die gegevens versturen naar de FOD financiën zoals banken, ziekenfondsen, sociale secretariaten, notarissen, ...

Of het daadwerkelijk EXACT dezelfde naam is zou ik zelfs in twijfel durven trekken, want veel mensen hebben in België meerdere voornamen terwijl in de praktijk enkel de eerste voornaam wordt gebruikt. Mijn 3e voornaam hebben ze zelfs ooit op eigen initiatief afgekort naar D op mijn identiteitskaart, terwijl die daarvoor wel voluit geschreven was.

[Superbra]

En namen worden soms verkeerd geregistreerd. Zolang er menselijke invoer is, zullen er fouten gebeuren. En je kan het proberen, maar alle fouten opvangen is naar mijn ervaring onmogelijk. Je kan een programma gewoon niet waterdicht maken. Er is altijd wel iets dat over het hoofd gezien wordt.

[RubjeMazter]

Iets met hondjes die Fikkie heten... Hoe kan je in hemelsnaam zo'n systeem in stand houden als er geen GUID of UUID aan een persoon gekoppeld is? En waarom heeft het 8 maanden geduurd voordat dit was opgelost?

[MrMonkE]

Het is het aanleverende systeem van Klunssukkeldorp waar 10 mensen wonen zijn de namen uniek genoeg maar zodra ze het het systeem van de overheid inschieten ontbreken er zaken.
Ga maar BSN nummers invoeren Klunssukkeldorp, Tot die tijd mag je niets aanleveren.

[Reactie gewijzigd door MrMonkE op 22 juli 2024 15:57]

[Floris4970]

Dit vind ik dus ook bizar.. hoe kun je dit soort informatie ooit zo benaderen. Doe het dan op zijn minst nog via een BSN.

Maar ik kan me zo voorstellen dat alles wel netjes een ID heeft. Maar dat een of andere sukkel heeft gezegd "select files where name is userStructure.name" en dat niet via het ID heeft gedaan.

Eng dat dit soort software bij een overheid een plaats krijgt. Want reken maar dat er heel dik voor betaald is..

[Maloney]

Er was dus geen rijksregisternummer, de Belgische versie van het BSN, aan deze gegevens gekoppeld. Daarom ging het juist fout. Er zijn blijkbaar in België instanties die gegevens overmaken aan de belastingdienst zonder BSN waarna een ambtenaar deze op naam aan de juiste persoon moet koppelen. En er is dus ook niet gekeken naar geboortedatum.

[Alex3]

Er zijn zelfs mensen met dezelfde naam en geboortedatum.

[MrMonkE]

En geslacht. Hebben ze er dan maar voor gekozen ze gewoon aan alle matchende records te koppelen?
Lijkt er wel op.

[CivLord]

Er zijn twee- en drielingen, geboren op dezelfde datum, met dezelfde achternaam en dezelfde voorletters. Dat is vragen om problemen. Niet elke instantie of organisatie mag BSN gebruiken 3n vaak worden gegevens dan gekoppeld door initialen, achternaam en geboortedatum.

[supersnathan94]

Ja eh. Das wel heel makkelijk.

Dit is ook van de regering gewoon niet oke, want dit had je natuurlijk van tevoren kunnen bedenken als je dingen op naam doet.

In Nederland heb we ook tig Jan Jansen’s dus heel raar om daar geen requirement voor op te nemen.

Is natuurlijk ook gewoon standaard procedure normaliter dus vraag me wel af hoe dit zo is gekomen.

[Paterpor]

Sorry ik had misschien wat context moeten geven.

ICT projecten in de gezondheidszorg of sociale sectoren worden al jaren door één bedrijf gedaan. Doordat het bedrijf zowat zonder moeite alle projecten binnenrijft en daar ook nog eens (te) veel voor betaald worden doet dat bedrijf geen moeite meer om het goed te doen. Is al jaren zo en dit is niet de eerste keer dat er zoiets gebeurd als dit voorval.

[TheFoundation101]

Smals is een fusie van de interne IT-diensten van die gezondheidszorginstanties (en andere actoren in sociale zekerheid). Het functioneert dus als een interne dienst, en is zelf een aanbestedende instantie.

Ze "rijft" bijgevolg geen projecten binnen. Ze kan niet meedingen naar opdrachten. Een instantie kan vrij kiezen of ze een project door Smals laten uitvoeren (het equivalent met het intern laten doen), of dat ze via Smals een aanbesteding uitschrijven die het overlaat aan een externe partij.

Daarnaast heeft Smals niks te maken met Financiën - dat je ze aanhaalt in je comment toont vooral dat je zelf geen flauw benul hebt hoe het in elkaar zit.

[pieterdebie]

Tax-on-web is niet van Smals en staat zelfs niet in de lijst die je linkt.

[Hyronymus]

Heb je ook inhoudelijk bewijs voor die stelling? En waar ligt de verantwoordelijk van de afnemer als Smals het zo (onhandig) uitgedacht heeft?

Edit: scherp gezien @pieterdebie!

[Reactie gewijzigd door Hyronymus op 22 juli 2024 15:57]

[Paterpor]

Het was nog scherper geweest als hij daadwerkelijk verder had gekeken dan puur projectnaam. Smals maakt eID en is een, wat ze zelf noemen, herbruikbare dienst waar ze personengegevens bewaren. Uit die databank vissen alle overheidsdiensten hun gegevens.

[pieterdebie]

eID is een manier van identificatie in IAM dat gebruikt kan worden, dit artikel gaat daar totaal niet over. Frapant ook dat dit artikel gaat over een probleem met een toepassing die Smals net niet gemaakt heeft maar dat je precies toch blijft vissen naar een oorzaak bij Smals?

[Anoniem: 340120]

"dit had geen effect op de vereenvoudigde aangifte, dat hoeft u niet na te kijken" mis ik nog :-)

[Damic]

Hoe kan dit nu? Al de documenten van en naar de overheid is op je rijksregister nummer