Te vroege IT-update koppelde klantgegevens en betalingen verkeerd bij Helan

Het recente datalek bij het Belgische ziekenfonds Helan is het gevolg van een te vroeg in productie genomen update van het eigen klantenbeheersysteem. Een menselijke fout is de eigenlijke oorzaak, zo heeft Tweakers nu achterhaald.

Klanten van het Belgische ziekenfonds Helan hebben recent persoonsgegevens van andere klanten te zien gekregen. Door een verwisseling van deze gegevens zijn digitale en fysieke post verkeerd bezorgd. Daarnaast werden betalingen van klanten getroffen. Sommigen kregen een terugbetaling die niet voor hen bedoeld was, terwijl anderen juist moesten wachten op een terugbetaling waar ze recht op hadden.

"Het technische incident werd veroorzaakt door een softwarebug in ons interne klantenbeheersysteem", vertelt een woordvoerder van Helan aan Tweakers. Die geeft aan dat dit systeem is ontwikkeld door de eigen IT-afdeling, die het systeem ook beheert. Het 'is geen cloudtoepassing of externe software'. Dit staat in tegenstelling tot de situatie bij de Nederlandse zorgverzekeraar CZ, die eind augustus een datalek had. Daar lag de oorzaak bij een externe IT-dienstverlener.

Bij Helan heeft een toegepaste update op het eigen klantenbeheersysteem een bug veroorzaakt. Daardoor zijn gegevens en betalingen van klanten gekoppeld aan de verkeerde personen. "De bug werd geïntroduceerd door een update die door een menselijke fout te vroeg in productie is gebracht", antwoordt de woordvoerder op vragen van Tweakers.

"We hebben de update intussen teruggedraaid en nemen bijkomende maatregelen om te vermijden dat dergelijke fouten zich in de toekomst opnieuw voordoen." De woordvoerder gaat niet in op vragen over welke maatregelen zijn genomen om het voortijdig installeren van updates − en de daaruit voortkomende gegevensfouten − te voorkomen.

Na het terugdraaien van de foute update hebben 'onze IT-collega's de gegevens maximaal gecorrigeerd', laat de woordvoerder weten. Klanten van Helan zijn bij de melding van dit datalek direct geïnformeerd over het feit dat het incident is opgelost. Het is nog altijd niet bekend hoeveel Helan-klanten zijn getroffen.

Reacties (27)

[Stroopwafels]

Nog steeds een beetje vaag verwoord, maar vanuit een technisch perspectief kunnen we waarschijnlijk aannemen dat er iets is misgelopen bij de koppeling van primary/foreign keys (of de joins in de SQL queries hiervan) tijdens/na database migration scripts?

[Reactie gewijzigd door Stroopwafels op 8 september 2025 09:06]

[t2012]

Dat is denk ik iets te specifiek dat je ervanuit gaat dat dit met SQL wordt gekoppeld. Vaak is het niet 1 systeem wat ze gebruiken wat de gegevens met koppelingen bij elkaar brengt. Mijn verwachting is deze koppeling niet goed werkte en dus een andere willekeurige klant koppelde. Dus een verkeerde bouw/inrichting van de koppeling. Je heb dus een financiele stuk en het nieuwe klantenbeheersysteem. Het zou bijvoorbeeld kunnen dat in sommige gevallen bij het koppelen van de betaling aan een klant meerdere resultaten naar voren komen en dus de eerste willekeurig wordt gekoppeld. Dit zorgt voor de lek van de gegevens.

Deze koppeling worden (gelukkig) bijna nooit met SQL gedaan waardoor het vaak niet een query fout maar eerder een verkeerde lookup tussen het enne systeem en de andere.

[Meteen]

En een lookup is niet zoiets als een query?

[Hoover]

T2012 bedoelt hiermee geen SQL query. Dit zijn waarschijnlijk API calls naar backends waarmee dan de data word opgehaald.

[t2012]

Klopt er zijn echter ook bedrijven die andere 'exotische' manieren gebruiken om hun data te publiceren. Soms kunnen ze alleen een CSV dump maken en dan heb je vaak weer third party software die er een soort dataportaal van maken. SQL verbindingen kan wel maar vormt een enorm risico in de beveiliging. Er zijn weinig beheerders die er tijd in steken om goed de rechten in te stellen. Daarnaast wordt het ophalen van gegevens niet gelogd en kan het op een verkeerde manier ophalen van de data locks op de database geven waardoor de oorspronkelijke applicatie gelockt wordt. Gebruikers zullen dan aangeven dat de applicatie traag is.

[Hoover]

Gegevens die opgehaald worden kunnen wel gelogd worden.
Doen wij ook.

Verder met je eens.
Met meerdere applicaties naar dezelfde database verbinden is vragen om problemen.
Genoeg mee te maken gehad en geoptimaliseerd.

Performance, maar ook rechten binnen een database, verantwoordelijkheid van de data etc.

Uiteindelijk gaan mensen "optimalisaties" doen door dan data uit die grote bak te halen en naar een eigen database kopieren. Alleen krijg je dan weer sync issues of lock issues waar niet uit te komen is. Dergelijke oplossingen doe je hooguit voor een datawarehouse oplossing en dan alleen op momenten waar het systeem niet belast is.

Bedrijven moeten gewoon de API's gebruiken (mits ze beschikbaar zijn uiteraard) van de backends zelf.
Zijn er problemen, kun je het probleem eenvoudiger bij de fabrikanten van dat systeem neerleggen.
Ga je zelf allerlei SQL queries uitvoeren op een database van een fabrikant en er ontstaan zo issues, zullen de meeste fabrikanten zeggen dat dat niet de bedoeling is en je geen hulp meer bieden.

En CSV... bedrijven die hun proces automatisering nog grotendeels via batch doen...
Die adviseer ik snel om over te stappen op betere en schaalbaardere technieken

[Hoover]

Zo is dat (in ieder geval hier in NL) bij de meeste het geval.

Vaak werken dit soort bedrijven met een CRM systeem waarbij dan aan een klantkaart 1 of meerdere externe bronnen worden gekoppeld waarmee data elkaar word gekoppeld.
Vaak heb je dan een facturatie administratie, polisadministratie, klantenadministratie etc.

En als dan door een bug aan een klant een verkeerde link aan de facturatie administratie word gekoppeld,
krijgt de klant facturen van andere klanten.

[incapable]

Och er zijn tientallen mogelijkheden waarop dit mis kan gaan, ook buiten de database. Er is niet gemeld of het tijdens de update fout ging, of slechts alle data die gemuteerd is na de update.

Daar kun je echt alleen over speculeren.

[SunnieNL]

onze IT-collega's de gegevens maximaal gecorrigeerd

Kan iemand mij even helpen.. is "maximaal" hier hetzelfde als "volledig"??
Want in mijn nederlandse beredenering is dit nu zoiets als "wij hebben ons best gedaan om alles te corrigeren, maar dat is niet 100% gelukt"

[IStealYourGun]

Diplomatiek antwoord. Als ze zeggen volledig en er zou een klant beweren dat het niet klopt, dan krijgen ze de wind vanvoor, zelfs als de bewering van de klant fout is.

[Hoover]

En in een kleine aanpassing in die zin kunnen ze ook zeggen dat de collega die dit veroorzaakte ook maximaal gecorrigeerd is.

[SPee]

Het is "wij hebben ons best gedaan om alles te corrigeren en hebben dat zover we kunnen achterhalen goed gecorrigeerd. Maar we kunnen of durven niet met volledige zekerheid te zeggen dat het ook het geval is. We kunnen gegevens gemist hebben of verkeerd hebben gecorrigeerd. Dus onze techs steken hun handen daarvoor niet in het vuur."

Dus ze hebben hun best gedaan, maar gaan vanaf nu alleen op basis van meldingen reageren.

[theduke1989]

ik heb hier wel gemengde gevoelens bij.
1. het is goed dat een ziekenhuis software in eigen beheer heeft, speciaal voor hun klantenbeheer,
2, andere kant, juist dat het dan weer gebeurd, als je weet wat je hebt gebouwd?

[Blokker_1999]

Het gaat hier niet om een ziekenhuis, maar een ziekenfonds. Dat is een dienst die de wettelijke terugbetaling van zorgkosten voor je kan regelen en meestal ook nog wat extralegale voordelen daar bovenop biedt, zoals vakantiekampen voor jongeren, beschikbaar stellen van hulpmateriaal voor ouderen en dat allemaal aan een zachte prijs, maar daar wel een bijdrage voor vraagt.

En waar mensen werken, worden fouten gemaakt. Maakt niet uit of het in-house of extern is. Maar fouten zullen altijd gemaakt worden.

[Ayiko]

Ziekenfonds, geen ziekenhuis. Ze regelen enkel de (verplichte) ziektekostenverzekering, ze doen zelf geen medische handelingen.

En het is niet omdat je het systeem zelf hebt gebouwd dat je weet wat je hebt gebouwd, helaas. Die ene die er alles van wist, als die er al was, is waarschijnlijk op pensioen of ergens anders begonnen, en dan moet de rest het maar zien uit te vogelen. (Geen idee of dat hier het geval is)

[veltnet]

" Na het terugdraaien van de foute update hebben 'onze IT-collega's de gegevens maximaal gecorrigeerd', laat de woordvoerder weten."

Nu loop je het risico dat de data alsnog fout is....

Waarom geen backup terug gezet en dan nieuwe (goede) update uitvoeren?

[Niemand_Anders]

Het ging ook onder andere om digitale post, en als je een backup terug zet, zet je alles terug en daardoor kunnen processen een tweede keer draaien. Echter sommige externe systemen staan niet toe dat een process een tweede keer wordt gestart. Bijvoorbeeld een inbound email kan al als gelezen zijn gemarkeerd waardoor deze na een backup restore operatie niet meer wordt ingelezen.

Men heeft waarschijnlijk via de wijzigingen in de update een goed beeld gekregen welke gegevens verkeerd zijn bijgewerkt. Soms kan men een backup terug zetten op een alternatieve database en dan selectief data uit de backup overschrijven in de productie database.

Het grootste probleem met geautomatiseerde testen, is dat ze elk hun eigen stukje testen, dus je verwerkt een bericht en controleerd of de gegevens in de database zijn bijgewerkt. Je kunt minder gemakkelijk controleren of onbedoeld ook niet iets anders is aangepast.

[supersnathan94]

Bijvoorbeeld een inbound email kan al als gelezen zijn gemarkeerd waardoor deze na een backup restore operatie niet meer wordt ingelezen.

Read Once E-mail?

Echter sommige externe systemen staan niet toe dat een process een tweede keer wordt gestart

mja onder bepaalde condities snap ik die, maar over het algemeen zou je wel idempotent willen werk toch?

Je kunt minder gemakkelijk controleren of onbedoeld ook niet iets anders is aangepast.

Side effects zijn sowieso een no-go. dat zou by design al niet mogen. Kan natuurlijk een bugje zijn he, maar dat is absoluut niet de bedoeling. Daar heb je overigens wel degelijk abstractere tests voor die veel meer kijken naar de algehele staat van het systeem na een specifieke actie. daarmee zou je dergelijke drift/anomalies wel moeten kunnen detecteren.

[Mortis__Rigor]

Dan ga je er al vanuit dat het een data issue is en niet gewoon een bug in de software die ergens een verkeerde call doet. Als het effectief een data issue zou zijn, is een backup terug zetten ook niet altijd wenselijk, want je mist dan een hoop data van na dat specifieke tijdstip. Het is meestal niet zo simpel om die data terug correct te kunnen inputten (in vermoedelijk x systemen). Stel dat je die data terug zou kunnen afspellen, zit de kans er bv. in dat je mensen die nu wel correct zijn terugbetaald, dubbel gaat terugbetalen (want het systeem weet niet meer dat je dit al hebt gedaan).

[veltnet]

Ja er was een issue met de data, want die moest gecorrigeerd worden. Je gaat geen data corrigeren als alles ok is.

En als je een diff maakt tussen de database backup en de corrupte productie versie dan zou je kunnen zien welke nieuwe records id's er zijn toegevoegd.

[Webgnome]

Dat er een issue met data was, dat was overduidelijk. Dat niet alles ok was ook. De oorzaak lag dus waarschijnlijk bij een code fout ( migratie die mis ging, if/else verkeerd you name it ). Je kunt een diff maken van je backup en je prd en dan op die manier dingen controleren echter is het lastig om te bepalen of je er dan klaar mee bent immers zijn er ook andere systemen die er mee communiceren waarschijnlijk, daar zul je dan een backtrack moeten toepassen om te kijken wat er precies gekoppeld zit aan het nieuwe en hoe dat zich verhoud tot het oude. Het is in ieder geval niet even een backupje terug zetten, diffen en klaar.

[supersnathan94]

Stel dat je die data terug zou kunnen afspellen, zit de kans er bv. in dat je mensen die nu wel correct zijn terugbetaald, dubbel gaat terugbetalen (want het systeem weet niet meer dat je dit al hebt gedaan)

Maar dan is je event store toch compleet nutteloos?

Buiten dat om, je gaat toch je state opnieuw opbouwen en niet direct al je acties opnieuw uitvoeren?

Ander worden alle bestellingen opnieuw ingeschoten, want het systeem weet nog niet dat de order al fullfilled is.

[Blokker_1999]

Backups zijn een last resort. Als je met data migratie bezig bent dan wil je liefst vooruit blijven gaan in plaats van achteruit. Want met achteruit gaan met een systeem dat in productie heeft gestaan, wat hier het geval was, verlies je dus alle data die sinds de laatste goede backup is ingevoerd geweest. En dat wens je meestal helemaal niet. Dan is het vaak net beter de fouten te herstellen door vooruit te gaan maar de nieuwe data mee te nemen dan terug te gaan en met heel veel zorg de in tussentijd verzamelde data te migreren zonder bijvoorbeeld betalingen 2x uit te voeren.

[Tubby]

Omdat het terugzetten van een backup ook inhoud dat andere gegevens naar een ouder moment worden terug gezet. Dat is (bijna) nooit gewenst.

Bij een dergelijke changelog-gone-wrong is het uithuilen en kijken of je een nieuwe changelog kan schrijven op basis van (een deel) van de oude backup gerestored in een los schema / table. Maar handwerk/rework it is :)

[Stijnvi]

Een menselijke fout is de eigenlijke oorzaak, zo heeft Tweakers nu achterhaald.

Dat is het toch altijd? Of hebben we inmiddels ook bedrijven die volledig autonoom door computers/AI worden gerund en waar geen enkele werknemer of bestuurder meer bij betrokken is?

[Djerro123]

Een menselijke fout wordt meestal aangehaald als er iets is gebeurd wat niet volgens proces is gegaan. Bijvoorbeeld: “zet jij release 5.21 in productie?” en dat er dan per ongeluk release 5.22 wordt gedeployed want die stond al in de staging environment (ik noem maar wat). Het probleem had zich dan niet voorgedaan, want de “foute” release was gesignaleerd door het proces (eg QA), maar is door een menselijke fout dus niet ondervangen door het proces.

maar goed, je hebt ergens een punt, uiteindelijk zijn alle fouten menselijke fouten (vooralsnog nu CPUs nog deterministisch zijn )

[supersnathan94]

Nouja: https://www.reddit.com/r/OpenAI/comments/1m4lqvh/replit_ai_went_rogue_deleted_a_companys_entire/

https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/


Het kan ook allebei zijn.