Flevoziekenhuis laat e-mailadressen van 800 patiënten uitlekken

Het Flevoziekenhuis in Almere heeft donderdag per abuis de e-mailadressen van 800 patiënten laten uitlekken. Dat gebeurde toen er een mail werd verstuurd met informatie over een nieuwe app en het gebruik ervan.

Volgens het ziekenhuis ging het voornamelijk om patiënten bij de maag-, darm- en leverafdeling. Bij het verzenden van de e-mail rond 16.30 uur werd geen gebruik gemaakt van de bcc-functie, waardoor de patiënten de e-mailadressen van andere personen konden zien, schrijft Omroep Flevoland.

Inmiddels loopt er een onderzoek over hoe het lek heeft kunnen ontstaan. Ook heeft het ziekenhuis het datalek gemeld bij de Autoriteit Persoonsgegevens. Bedrijven en instellingen zijn volgens de Algemene Verordening Gegevens, ofwel AVG, verplicht om na het ontdekken van een datalek dat binnen 72 uur te melden bij de privacytoezichthouder.

Reacties (108)

[JJ Le Funk]

Oorzaak van het probleem is niet 'BCC veld vergeten te gebruiken', maar de standaard werkwijze: lijsten met emailadressen intern beschikbaar stellen om te copy paste'en voor patiëntcommunicatie.

[Polydeukes]

Dat is speculatie. Ik kan zo een aantal use cases bedenken waarin het uit te leggen valt dat een medewerker de beschikking heeft over een lijst met mailadressen van patiënten. Om er een te noemen: deelnemers aan wetenschappelijk / bevolkingsonderzoek die geïnformeerd worden door de onderzoeker over de resultaten van dat onderzoek. Ja, idealiter verstuur je zo'n mail via een communicatieplatform, maar in een ziekenhuis is daar vaak geen geld voor ivm andere prioriteiten. Niet meteeen oordelen als je de details niet kent.

[JJ Le Funk]

Je impliceert dat het Flevoziekenhuis geen geld heeft voor een degelijke technische oplossing, juist dàt schaar ik onder speculatie.

[RoosW]

Hmm https://www.omroepflevola...n-bezuinigen-noodzakelijk Niet echt speculatie als het klopt toch??

[Tc99m]

Dat een ziekenhuis (of bedrijf) moet bezuinigen wil niet zeggen dat er helemaal geen geld meer is. De begroting van het Flevoziekenhuis is 204 miljoen, dus met 14 miljoen aftrek blijft er gelukkig nog wel wat over. En zo duur zijn dit soort oplossingen nu ook weer niet (in ieder geval niet duurder dan alle bulkmails met de hand versturen...).

[iam2noob4u]

De werkelijke kosten zitten in het opzetten van een dergelijke oplossing. Dat de leverancier niet veel vraagt, is naar mijn mening niet voldoende om te beargumenteren dat het niet duur is om te doen.

Een maillijst hebben en de medewerker laten copy pasten snapt iedereen en is goedkoop om op te zetten.

Ik zeg niet dat ze het niet hadden moeten doen, maar het is niet zo'n simpele keuze als meerdere mensen hier impliceren.

Edit: grammatica middelste alinea.

[Reactie gewijzigd door iam2noob4u op 23 juli 2024 00:49]

[Tc99m]

Er is anno 2024 geen enkel ziekenhuis in Nederland dat geen systeem heeft om patiënten via e-mail (of een andere digitale weg) te informeren, aangezien 90% van alle communicatie vanuit het ziekenhuis digitaal is (incl. gevoelige communicatie via beveiligde e-mail of een portaal met digid-inlog voor bijv. uitslagen).

Het lijkt me sterk dat dit ziekenhuis dat pas in 2023 is gaan implementeren en het is dus ook niet voldoende om te beargumenteren dat bezuinigingen die in 2023 zijn aangekondigd, aanleiding zijn om te denken dat het ziekenhuis geen geld heeft voor fatsoenlijke communicatiemiddelen.

[Blokker_1999]

Het is goedkoop om op te zetten ... tot de dag dat het misgaat.

En het is een process dat ontworpen is om mis te gaan!

Net daarom wil je de juiste software gebruiken. Je schrijft een template, bezorgt een lijst met de variabelen (naam, email adres, specifieke details die je in de gepersonaliseerde mail wenst te zetten, ...) klikt op de knop en weg is de mail. Individueel naar elke ontvanger. Iedereen die netjes wordt aangesproken met zijn/haar/hun naam.

En ja, dat is ondertussen zo een gestandarisserd iets te noemen dat het echt wel een simpele keuze kan zijn. Temeer wanneer je regelmatig naar mensen moet mailen met gevoelige informatie.

[JJ Le Funk]

U mist het punt: los van budget kan er prioriteit gesteld worden aan patiënt data en privacy (evt. met open source gebruik in het achterhoofd) te beginnen met een verbeterde werkwijze in de communicatie die nu kennelijk vanaf de PC op de receptie van elke poli d.m.v. Outlook wordt geregeld (vandaar schade beperkt tot Maag/Darm/Lever poli).

[Guru Evi]

Het probleem is meestal niet het geld dat in de grote pot zit, het geld dat naar een specifieke groep of departement gaat is vaak niet genoeg.

Daarnaast zijn er kosten aan die oplossingen, niet alleen geld maar ook tijd. Als de medewerker al weet welke oplossing hij moet gebruiken, kan het vaak uren/dagen/weken duren alvorens de centrale IT een lijst opzet omdat dit door vergaderingen en reviews etc etc moet en al die 'veiligheidsdingen' kosten tijd en dus geld (wie mag de lijst gebruiken, waar komt de lijst vandaan, waarom, wat gebeurt er met antwoorden op de mails, hebben die mensen toelating gegeven, hoe weten we dat). Tegen dat we gedaan zijn is het 6 maand verder en weten we al lang niet meer wat we eigenlijk moesten doen.

Dus als je vandaag een mailtje wilt sturen is het Outlook open doen -> CC iedereen erin en het probleem is opgelost, geen ITer nodig, geen vergadering waar je moet uitleggen wat je wilt doen, geen vragen over de privacy.

En natuurlijk kunnen de meeste slimme mensen wel een manier vinden om dit gemakkelijker te laten werken, echter die mensen werken meestal niet voor de overheid of voor de ziektezorg. In de meeste gevallen moet er bespaard worden en degelijke lonen voor IT is het eerste dat aan de kant gezet wordt.

[Reactie gewijzigd door Guru Evi op 23 juli 2024 00:49]

[Tc99m]

Je hebt gelijk dat er usecases zijn waarbij medewerkers over contactinformatie kunnen beschikken, maar ik kan me niet voorstellen dat een Nederlands ziekenhuis alle mailings met reguliere e-mailclients doet.
Zij moeten een tool tot hun beschikking hebben om bulkmails mee te kunnen versturen. Daarnaast zullen zij net als bijna ieder ziekenhuis in Nederland een online patiëntenomgeving hebben waarop je informatie kunt delen.

[Aldy]

Ik kan mij ook niet voorstellen dat er in Nederland nog één ziekenhuis is dat geen gebruik maakt van een online patiëntenomgeving, dat alleen bereikbaar is via DigiD. Dus wat er fout is gegaan in het Flevoziekenhuis zal ingewikkelder zijn dan het lijkt op het eerste gezicht. Als het zo eenvoudig was zou er ook geen onderzoek ingesteld hoeven te worden.

[Caelorum]

Sowieso zo'n aantal in een CC of TO veld zou al meteen geblokkeerd moeten worden. Er is echt geen enkele reden om zoiets te moeten willen.

[bzuidgeest]

Dan moet je wel specifiek externe adressen tellen, want bedrijfs interne mailings gaan soms ook naar grote groepen.

[Caelorum]

Als je naar grote groepen mailt doe je het maar met een BCC of vraag je een uitzondering aan.
Ik kan me echt niet voorstellen dat het ooit nodig is naar meer dan 10 mensen in een cc of to een mail te sturen.

Het verhelpt ook niet dat er data gelekt wordt, maar kan wel de omvang van het lek aanzienlijk beperken.

[bzuidgeest]

Nooit van mailing lists gehoord zeker , de voorloper van web fora en nog steeds in gebruik links en rechts

Maar ook in grote project groepen komt meer dan 10 makkelijk voor.

Het feit dat jij er geen reden voor kan verzinnen, maakt het nog geen werkelijkheid.

[Caelorum]

Ik ben nog geen mailinglist systeem tegen gekomen die zoveel mensen in een tonof cc veld zet.

En massa mails naar iedereen in een projectgroep kunnen ook gewoon in een BCC. Als je iets te melden hebt, maar echt specifiek antwoord op wilt krijgen dan is, gerichter mailen een veel betere optie dan een massamail. En als het gewoon een mededeling is dan kan dat dus prima via de BCC.

Het is zeker de werkelijkheid en dat ontken ik niet, ik ontken vooral dat er een noodzaak is om die werkelijkheid in stand te houden. En nee, ik vind verouderde processen en IT inrichting niet een goede reden.

[bzuidgeest]

De reden is meestal kosten en ik betwijfel of jij de rekening betaald . Dus we leven met oude rommel, jammer, maar waar.

[Caelorum]

Prima, als zo'n bedrijf dan ook even de boeten gaat betalen.
Ik betaal met liefde een extra taks op mijn zorgverzekering als dat betekend dat dit soort zaken daar goed geregeld gaan worden.

En met oude rommel leven blijft een keuze he. Ik zie dagelijks hoe partijen winst en bezuinigen boven privacy en veiligheid stellen. En ik ben er ook dagelijks mee bezig om mensen er aan te herinneren dat, dat dus echt niet kan. Altijd wordt er weer geschermd met budgetten, maar dat is nooit het probleem. Er is altijd beperkt budget, maar het gaat over prioriteiten stellen.

Ik kan vanaf hier uiteraard niet zien welke processen en prioriteiten ze hebben, dus ik hoop maar dat ze er vooral voor zorgen dat het niet nog een keer gebeurd, maar 1 ding is in ieder geval al wel duidelij voor mij: hun mailserver staat niet goed ingesteld of de mensen hebben geen goede training gehad.

[Reactie gewijzigd door Caelorum op 23 juli 2024 00:49]

[Verwijderd]

Het zijn allemaal verschillende bedrijven die allemaal het wiel hebben uitgevonden. Per afdeling zijn het ook weer aparte entiteiten, hun overleggen wellicht bedrijfsbreed maar hun expertise is zorg, geen it. Als de stagiair ff een mailing moet verzorgen met oude meuk vaak, is het wachten op zo'n fout. Maarja het is maar een emailadres wat is gelekt

[bzuidgeest]

Soms is de keuze geld naar betere zorg of naar it en kiezen ze zorg. Die keuze zegt niet dat privacy onbelangrijk is, alleen dat er een limiet aan het budget zit.

[massareal]

...ik zou niet weten waarom jij extra "taks" wilt betalen, maar zou toch eerder het balletje bij de zorgverzekeraar neerleggen. Die maken ruim voldoende winsten om dit soort dingen te vergoeden. Vergeet niet dat de zorgverzekeraars de ziekenhuizen uitknijpen voor winst maximalisatie...en als dat niet(voldoende) lukt, gaan de premies weer omhoog!

[massareal]

Het is relatief makkelijk om verschil tussen externe(andere behalve lokale) domein te filteren.
Tevens zou je niet iedereen naar grote groepen mogen laten mailen.
Waar ik werkte was dit afgekapt standaard, enkel adressen waren uitgezonderd en bepaalde groep kon tijdelijke ontheffing aanvragen indien nodig.

[bzuidgeest]

Zelfs als je het aantal mensen dat het kan beperkt, dan kan een van die mensen nog steeds een fout maken.

[massareal]

...de mens heeft de meeste kans op het veroorzaken van een fout.
Uiteraard kan je het niet uitsluiten, enkel dicht timmeren....ongeacht of het door onkunde, onoplettendheid of misbruik is.

[Blokker_1999]

Intern ga je gewoon ditributiegroepen gebruiken. En met standaardinstellingen is het vaak zelfs niet mogelijk om naar zoveel mensen in 1 keer te sturen.

[bzuidgeest]

Ik verwacht dat hier ook gewoon een mail groep of distributie groep is gebruikt, dat veranderd weinig aan dat iedereen in de groep in mail krijgt. Ergens onderweg wordt die groep uitgesplitst naar losse adressen.

[RiDo78]

Nou dat lijkt makkelijker dan het is, maar het is zeker niet onmogelijk.

Beetje achtergrond info, alle emailadressen die je gebruikt in de TO, CC of BCC velden kunnen op twee plekken gebruikt worden. De eerste is in de header van de mail, daar vind je de TO en CC headers terug. De tweede plek is in control-channel data die de versturende server mee krijgt. Daar vind je alle adressen terug, maar is niet te herleiden of het een TO, CC of BCC adres betreft, elk adres is onderdeel van een SMTP commando, RCPT TO <email@adres>. De mailservers werken vooral met die tweede set adressen, de mailclients krijgen de tweede set niet en werken enkel met de eerste set.

Intern in de versturende mailserver worden alle op een hoop gegooid en gegroepeerd per maildomain (MX-record). Op dit punt weet de versturende mailserver dus ook hoeveel kopieën er intern en extern verstuurd worden. Vervolgens wordt een voor een contact gelegd met alle ontvangende mailservers en wordt de lijst met (RCPT TO) adressen die voor die specifieke mailserver van belang zijn doorgestuurd, gevolgd door de mail (met eigen headers, inclusief TO en CC headers, maar zonder de BCC header). De ontvangende mailserver negeert de TO en CC velden in de mailheader en baseert zich vooral op de adressen die hij via de 'RCPT TO' SMTP-instructie heeft gekregen voorafgaand aan de mail.

De versturende mailserver heeft dus vrij goed inzichtelijk hoeveel kopieën er naar externe mailservers gaan. Het enige probleem is dat hij geen flauw benul heeft of het TO, CC of BCC adressen zijn. Daarvoor moet hij de mailheaders zelf gaan scannen en dat zit niet in zijn natuur. Maar zoals gezegd, het is niet onmogelijk. Je zou kunnen instellen dat een email met meer dan X externe ontvangers langs filter Y geleid wordt. En filter Y kan die mail scannen en de controle uitvoeren. Zo gek is dat niet, emails met attachments worden op dezelfde manier door een virusscanner gehaald en over spamfilters maar te zwijgen.

Dus het kan prima, maar het zit niet echt in de 'natuur' van het SMTP protocol. De mailserver hoort zich te baseren op de adressen die hij via RCPT TO commando's door krijgt. Dus of je het kunt implementeren zal sterk afhangen van de mailserver die je gebruikt en de mogelijkheid en eenvoud om daar filters voor te ontwikkelen.

[The Zep Man]

Sowieso zo'n aantal in een CC of TO veld zou al meteen geblokkeerd moeten worden.

Zeker als het zoveel externe adressen betreft. Een mailserver kan dit prima afvangen.

[Tc99m]

En de fout is: normale mailclient gebruiken voor bulkmailing, terwijl daar geschiktere tools voor zijn.

[TMDC]

En zelfs dan nog: bij mij waarschuwt Outlook "Move recipients to BCC - n external recipients will see each others' contact details. Move them to BCC to protect their privacy".

[Guru Evi]

Wij weten dat wel, weet Trien op de bureau dat?

[vickypollard]

Nee, maar hopelijk de IT-afdeling van Flevoziekenhuis wel? Die dat vervolgens weer kunnen afdwingen als werkmethode.

[Reactie gewijzigd door vickypollard op 23 juli 2024 00:49]

[fifanoob]

en dan heb je zo'n jan doedel die dat een keer vergeet en tadaa je hebt zo'n lek.

De boetes moeten gewoon hoger op dit soort zaken. Er zit te weinig prio op om dit fatsoenlijk dicht te timmeren.

[Guru Evi]

Je overschat de beslissingskracht van IT. De eerste zorg voor een ziekenhuis is de financiële overdracht van de overheid die altijd te klein is om fatsoenlijk iets mee te doen. Daarna is het plaats om bedden te zetten, de verpleger vakbond en een reeks andere zaken. IT zit qua belang en invloed achter de kleur van de muur en de man die het afval ophaalt.

[BCC]

Waarom staat een mailclient / server uberhaupt toe dat iemand dit doet in 2024? Ik kan geen enkele reden verzinnen om meer dan 10 mensen in de CC te hebben.

[Edward Dortland]

Ik heb er regelmatig meer dan 10. Paar projectmanagers, paar key users, paar collega's, paar leveranciers. Is vrij normaal voor wat grotere projecten. Ik zou dus persoonlijk niet zo blij worden van een rule op onze mailserver waarbij er maar 10 adressen in de to/cc mogen staan.

Waarom het misging bij het Flevoland is slechts gissen, zonder de waarom is een oplossing verzinnen onmogelijk. En verder: 800 e-mail adressen. Mijn hemel, we hebben wel grotere data privacy issues in Nederland.

EDIT: Ik lees nu dat de e-mail gestuurd is naar een groep patiënten met een specifieke aandoening. Dus de ontvangers weten nu van de ander dat ze een specifieke aandoening hebben. Dat maakt de informatie die gelekt is wel degelijk ernstig. Maar nog steeds zie ik niet de toegevoegde waarde van een persbericht, het oppikken van het persbericht door de media (zoals deze site) en vervolgens een grote groep mensen die dan op fora er van alles van gaat vinden zonder de feiten te kennen. Het voegt niks toe aan een beter beleid (of het beter opvolgen van een bestaand beleid). Sterker nog, ik denk dat het affakkelen van menselijke fouten alleen maar leidt tot het minder transparant willen zijn over je fouten.

[Reactie gewijzigd door Edward Dortland op 23 juli 2024 00:49]

[bzuidgeest]

Ze stellen waarschijnlijk geen adressen lijsten beschikbaar aan hun personeel, het personeel zal naar een doelgroep van een of andere vorm mailen. Maar op de achtergrond wordt dat rustig uitgepakt naar de individuele adressen door software. Dat is hoe dat werkt. De gebruiker hoeft dus geen toegang tot de lijst zelf gehad te hebben om dit te veroorzaken.

Wat ze wel hadden kunnen doen is hun mail software/server regels geven dat meer dan x aantal externe email adressen in een aan of cc niet is toegestaan, dan had de mail niet uitgestuurd geworden.

[caspervc]

Tja, waar mensen werken worden er fouten gemaakt. Dat zal tot in de eeuwigheid zo blijven.
Is het netjes: nee. Is het volgens de AVG: nee. Maar of een fout van iemand zo breed uitgemeten moet worden op diverse nieuwssites? Ik vraag het me af.
Misschien is het te ondervangen met een check, dat wanneer bijv. meer dan 25 man in de ‘aan’ of ‘cc’ staan, er wordt gevraagd of ze niet toevallig in de bcc moeten staan. Zou toch niet moeilijk (als pluging) te maken moeten zijn?

[The Realone]

De vraag is eigenlijk of patiënten wel gemaild dienen te worden via een email client die toestaat dit fout te doen. Daar zijn nou juist prima portals voor die dit kunnen beperken. Het handmatig invoeren danwel plakken van een lijst met honderden adressen in een To/BCC veld is niet bijzonder praktisch.

En inderdaad, dit is zo'n typisch menselijk foutje, maar wel 1 die al sinds jaar en dag voor komt.

[caspervc]

Inderdaad.
Eigenlijk zou je vanuit een closed administratie achtig systeem bepaalde patiëntengroepen moeten kunnen mailen. En daarmee altijd afgeschermd, dus via de bcc, of desnoods een hele bult persoonlijke mails.

Maar in mijn optiek is het zo onderhand wel een keer nodig om het gehele mailsysteem tegen het licht te houden. Is de manier waarop onze mail werkt (aan, cc, bcc) niet heel erg beperkend en onoverzichtlijk? Bovendien werkt het dit soort fouten in de hand, en ze worden -zo zien we al twee decennia nu- niet minder.

[gaskabouter]

Hoe werkt dat dan? Als ik mijn patiënt mail en ik zet mensen in de cc werkt het gewoon. En andersom zou ik het willen weten als patiënten, ook als dokter trouwens, mensen in de cc zetten bij mails?

BCC kan ook heel prima in je nadeel gebruikt worden

[The Realone]

Het voordeel van het via een portal doen is dat er zeer eenvoudig checks ingebouwd kunnen worden. Of dat het CC veld standaard niet zichtbaar is, maar je die met een extra klik moet tonen. En dan kun je daarbij ook eenvoudig een waarschuwing geven in de vorm van "Let op! Weet je zeker dat je het CC veld wilt gebruiken, etc...". Dan hou je die mogelijkheid, maar ben je wel veel bewuster van de actie.

[mjtdevries]

Ja, je kan voor elke situatie een portal bouwen.

Probleem is natuurlijk dat dit een situatie is die waarschijnlijk zeer zelden bij dat ziekenhuis voor komt (hoeveel apps hebben ziekenhuizen?) en er dus geen portal beschikbaar was. En alleen hiervoor ga je die niet bouwen.

Een CC veld wil je in een email client uiteraard wel zichtbaar hebben, want CC word in de praktijk veel vaker (nuttig) gebruikt dan BCC.

Zowel CC als BCC hebben allebei zinvolle redenen om te gebruiken.
En elke keer als iemand op CC klikt een waarschuwing geven is compleet zinloos, want dan gaan mensen automatisch die waarschuwing weg klikken.

Dan zou je alleen een waarschuwing moeten geven als er meer dan 30 mensen in de CC staan, zodat mensen de melding wel lezen.
(En dan gaat iedereen op tweakers bij een volgend datalek klagen waarom die melding pas bij 30 mensen werd gegeven)

[The Realone]

Nee natuurlijk bouw je geen portal om een eenmalige mail over een app uit te sturen, je bouwt een portal voor patiëntencontact in het algemeen.

[mjtdevries]

Het meeste contact zal met een enkele patient zijn en niet met groepen patienten en dan heb je geen portal nodig.

[The Realone]

We kunnen natuurlijk vanalles gaan verzinnen, maar het feit blijft dat een portal dit soort zaken prima af kan vangen. En een mail naar meerdere patiënten zal niet een dermate unieke situatie zijn dat het een vreemde feature request zou zijn, en in elk geval zal dat ook geen complexe feature zijn.
Sowieso heb ik regelmatig met portals gewerkt waar dit soort zaken al prima in kunnen. Niet medisch, maar CRM, maar de implementatie blijft hetzelfde.

Het lijkt me dat we er het op zijn minst over eens kunnen zijn dat het handmatig kopiëren en plakken van honderden emailadressen van patiënten in een veldje in een email client bijzonder foutgevoelig is en dat daar betere oplossingen voor te vinden zijn. En in mijn optiek ben je dat ook verplicht wanneer je in een omgeving werkt waar de data bijzonder privacygevoelig is/kan zijn.

[mjtdevries]

Ja, en het maken van een portal is één van die verzinsels.

Heel makkelijk te zeggen, maar je moet wel eerst budget regelen en als het dan in de praktijk gebracht moet worden dan komen er allemaal extra issues, want er zit allemaal gevoelige informatie in. Met waarschijnlijk als gevolg dat de persoon die deze mailing moest doen er niet in mag en heel veel moeite moet doen om wat verstuurd te krijgen.

[The Realone]

Je doet alsof dit soort portals niet al jaar en dag gemeengoed zijn en in nagenoeg elke organisatie wel al terug te vinden zijn. Als je nu nog je klant/patiënt gegevens in Excellijstjes of access DBs zit bij te houden moet je je schamen.

[mjtdevries]

Als jij denkt dat nagenoeg elke organisatie al hun externe communicatie via een portal doet, dan leef je met een roze bril op.

[The Realone]

Portal, CRM pakket, noem maar wat. Als jij denkt dat organisaties met honderden patiënten, klanten, of wat voor regelmatige contacten dan ook, enkel deze contacten bijhouden via een Outlook adresboek dan sta je ver van de realiteit, of ben enkel bekend met organisaties die duidelijk hun IT zaken niet op orde hebben. En dat laatste is prima mogelijk, maar absoluut ontoelaatbaar als het om privacygevoelige gegevens gaat.

Dat een bouwbedrijf een paar kuub hout wil bestellen en daarvoor handmatig een mail opstelt naar hun leverancier, maar per ongeluk de electricien in de CC zet is knullig, maar niet meer dan dat. In de zorg is dit ontoelaatbaar. Daarbij zijn er in de zorg al sinds jaar en dag kant en klaar pakketten voor dit soort toepassingen beschikbaar, daarvoor hoeft echt niet iedere keer het wiel opnieuw uitgevonden te worden.

[mjtdevries]

Voor regelmatige contacten ja. En dat probeer ik je al steeds uit te leggen: Dit was niet een regelmatig contact. En dan is er vast wel ergens een pakket wat voor die regelmatige contacten gebruikt word en als deze mensen dan voor dit eenmalige contact bij die afdeling aankomen dan krijgen ze vaak nul op het rekest. Want daar is hun Portal, CRM of wat dan ook niet op ingericht.

[The Realone]

Het gaat niet om hoe vaak je contacten benaderd, het gaat erom dat er slechts 1 plek is waar je die contacten beheerd. Het zijn patiënten en hun emailadres is onderdeel van de patiëntendata, dan moet je die ook in dat systeem laten.
Deze discussie begint verder een beetje zinloos te worden.

[mjtdevries]

Tja, het is een discussie in hoeverre de theorie overeen komt met de praktijk.

En afhankelijk van de positieve of negatieve ervaringen die je daarmee gehad hebt in bedrijven zal je mening daarover anders zijn.
Onze ervaringen komen duidelijk niet overeen.

[bzuidgeest]

Cc is bedoeld als alle betrokkenen, met elkaar willen mailen, dat is hier niet het geval, hier is het is communicatie van dokter naar patiënt, dus eenrichtingsverkeer.
Bcc werkt anders. Elk adres in bcc wordt behandeld als een op een mailing. Voor elk adres in de bcc komt een kopie van de email. Heel anders dan bij cc of aan, waar 1 mail naar velen gaat.
Bcc is gewoon in te voorkomen dat je 100 keer naar 1 persoon hetzelfde moet mailen.

[gaskabouter]

Ik weet hoe het werkt. Maar de keerzijde van bcc is dat je als ontvanger niet kan zien naar wie de mail nog meer verstuurd is. En dat kan in een zorgrelatie niet alleen belangrijk zijn maar zelfs wettelijk verplicht.

[bzuidgeest]

Maar de keerzijde van bcc is dat je als ontvanger niet kan zien naar wie de mail nog meer verstuurd is

Dat is totaal onbelangrijk in een mass mailings and deze. Sterker nog, van de privacy wetgeving, mag je het niet eens kunnen zien.
Ik weet niet wat jij denkt dat dit artikel over gaat...
Het was hier geen mailing aan een praatgroep of zo

[Tc99m]

Breed uitmeten is ook wat overdreven. Ik vind het goed dat zoiets in het nieuws komt, zodat mensen die vanuit hun werk (of privé, bijv. voor een vereniging waar ze actief in zijn) grote groepen mensen moeten mailen, en dat nu nog via hun reguliere mailclient doen (en dat zijn er een hoop) eens nadenken over tools die daar beter geschikt voor zijn. Zo voorkom je ook weer nieuwe incidenten.

[Blackjack2win]

Ik kan ook nog wel een situatie bedenken op mijn werk, waarin er intern een algemene communicatie lijst toegankelijk was voor iedereen.

Dit werd jarenlang gebruikt, totdat er een keer een BSN overheen werd verstuurd.
Gelukkig is alles intern gebleven tussen mensen die er ook daadwerkelijk mee werken, maar dit was van zowel ICT als de medewerker slordig en een wake-up call.

Nu zijn er aangewezen personen die toegang hebben tot deze algemene communicatie lijsten.
Het belangrijkste is dat er van wordt geleerd.

[Qwerty-273]

Misschien is het te ondervangen met een check, dat wanneer bijv. meer dan 25 man in de ‘aan’ of ‘cc’ staan, er wordt gevraagd of ze niet toevallig in de bcc moeten staan. Zou toch niet moeilijk (als pluging) te maken moeten zijn?

Dat kan je bijvoorbeeld al opvangen als je Exchange/Office 365 gebruikt met MailTips. Al is dat slechts een visuele waarschuwing en niet eentje die je nog expliciet moet bevestigen tijdens het versturen.

[Tjark]

Waarom is er nog geen instelling in mailprogramma's (in dit geval waarschijnlijk Outlook) dat >10-20 emailadressen in de TO: automatisch niet verzonden worden, of een heel duidelijke pop-up geven met advies de adressen in de BCC: te zetten?

[Polydeukes]

Volgens mij is in Outlook de standaardlimiet al 500 ontvangers. En dat zal ook vast nog wel te configureren zijn. Feit is dat bij kleine ziekenhuizen meestal weinig budget is voor ICT ondersteuning, scholing en awareness op gebied van privacy en security. Dus dat iets technisch kan, wil niet zeggen dat er ook aandacht voor is. Daarmee praat ik het niet goed, maar ik kan wel begrijpen dat het gebeurt.

[Mollos_]

Waar ik werk, en we met gevoeligere data werken, wordt vanaf dag 1 wanneer je in dienst komt een Privacy en Security sessie gegeven. Bespreken wij in maandelijke meetings of er gevallen zijn geweest waar de klant, of iemand van ons mogelijk een vergissing heeft gemaakt. Daarnaast hebben we jaarlijks een update sessie van Privacy en Security en leren we elkaar van begin aan om elkaar aan te spreken op dingen die niet goed gaan. Het begint al met kleine dingen zoals het niet locken van de computer.

Dit is geen ICT probleem. Dit is een mindset van het goed omgaan met gevoelige data. Dat ICT kan ondersteunen in het voorkomen van het lekken van data dat is zo. Maar in eerste instantie is het 90% van de tijd de mens die de fout maakt en zich niet voldoende bewust is van wat de impact kan zijn.

Mijns inziens is dit iets wat vanuit Privacy en Security opgepakt moet worden, en ze de personen opleiden in het goed omgaan met gevoelige data. Bij incidenten ga je dan kijken hoe je het de volgende keer kan voorkomen.

[Reactie gewijzigd door Mollos_ op 23 juli 2024 00:49]

[Polydeukes]

Allemaal waar. En toch geeft 't allemaal geen garanties. Geloof me, ik heb 't vaak genoeg gezien. Waar mensen werken worden fouten gemaakt, meestal onbewust onbekwaam.

[svennd]

Absoluut, opleiding en bewustwording zijn extreem belangrijk, de (technische) controle is ook maar dat. Mooi voorbeeld van hoe het moet.

[Reactie gewijzigd door svennd op 23 juli 2024 00:49]

[fifanoob]

Dan zou iemand niet voldoen aan de voorwaarden en zou wat mij betreft hun licentie afgenomen moeten worden.
Elke x maar het softe gedoe van ja ze hebben weinig budget en blabla, ik snap het wel maar het mag geen excuus zijn. Ik vind het onacceptabel.

Gegevens online zetten van mensen is verboden, strafbaar, dat is wat nu hier in principe ook deels gebeurd.
Zolang wij, de maatschappij het elke wel prima vinden, want ja waar mensen werken worden foutjes gemaakt of ja er is amper budget en weet ik veel wat, ja dan veranderd het niet zo snel. Op moment dat bij 2 van zulke foutjes een bedrijf zijn licentie/vergunning kwijtraakt, reken maar dat er dan opeens wel geld en tijd voor is.

[Coach4All]

Bij de meeste mailservers kun je dat instellen, maar het staat niet standaard aan.....

[bzuidgeest]

Omdat er goede kans is dat er naar een doelgroep werd gemaild, mogelijk vanuit maatwerk software met een mail functie. De gebruiker ziet niet meer dan de groep. Hij ziet niet hoeveel er in zit en niet de individuele adressen, dat is iets wat de server regelt.
Misschien gebruikt dat ziekenhuis Outlook voor mass mailings, maar alleen als ze graag zware privacy issues hebben.

[Polydeukes]

Het is echt heel pijnlijk en slordig, maar het kan de beste overkomen. Ik acht mezelf behoorlijk scherp op privacy en security, maar ik heb ook ooit per ongeluk een mail naar 100+ personen incl externen gestuurd zonder de BCC te gebruiken. Uiteraard keurig iedereen ingelicht en een melding gemaakt bij de FG en de AP, maar ik was er behoorlijk ziek van. Gelukkig reageerde de meeste mensen begripvol, en kende velen elkaars (zakelijke) e-mailadres al, maar toch gewoon een datalek en erg slordig.

Ik hoop vooral dat er in deze groep van 800 niemand zit die op het idee komt om de 'Reply All' knop te gebruiken...

[Tc99m]

Van een professionele organisatie zoals een ziekenhuis mag je toch wel verwachten dat ze geschiktere tools hebben om bulkmailings te versturen. Waarschijnlijk hebben ze die ook, maar weet dus niet iedereen die te vinden.

Is fouten maken menselijk: ja, maar hier is gewoon sprake van een organisatie die zijn zaakjes niet op orde heeft. Het is dus niet zozeer de fout van één persoon, maar de fout van een organisatie als geheel (waarvan de gevolgen redelijk zijn te overzien, behalve dat van 800 mensen bekend is dat zij worden behandeld voor een MDL-aandoening, waar wellicht niet iedereen zit op te wachten).

[Polydeukes]

Ik werk in 'n organisatie met bijna 4000 medewerkers en we hebben alle tools die nodig zijn om veilig en compliant te werken, maar je hebt maar 1 eigenwijze managementassistent nodig die "de tool niet snapt" en je hele informatiebeveiligings-- en privacyplan kan in de prullenbak. En ja, dat gebeurt.

[theduke1989]

"Inmiddels loopt er een onderzoek over hoe het lek heeft kunnen ontstaan. "

In de text staat hebben niet als BCC opgestuurd? wat moet je daar nog aan onderzoeken, de persoon in charge heeft een fout gemaakt. Stres, drukte noem maar op.

[Qwerty-273]

Onderzoek is dan ook vooral naar de protocollen/procedures die er liggen. En waarom zou je mail vanuit een standaard mail client naar 800 adressen moeten kunnen sturen? Bij een beetje standaard mail server/service kan je juist policies instellen om grote massa mailings te voorkomen. Waarom is dat hier niet van toepassing? Of waarom is daar hier van afgeweken? Dat kan je allemaal mee pakken met dat onderzoek.

Stress/drukte op de werkvloer, het verkeerde vakje gebruiken, ja dat is allemaal op één persoon te richten. Maar er zit veel meer achter. Zeker met alle digitale mogelijkheden om dataverlies te beperken, zou dit niet (meer) mogelijk moeten zijn.

[bzuidgeest]

De mailing zelf was gewenst, alleen is het verkeerde adres veld gebruikt.
Soms moet je gewoon grote groepen op de hoogte stellen.
We weten ook niet welke software werd gebruikt. Het is prima mogelijk dat de software alleen een doelgroep laat kiezen en zelf de doelgroep naar adressen vertaalt. Dat is wat ik zou bouwen als ik iets privacy gevoeligs moest inrichten. Dan heeft de gebruiker nooit de adressen nodig of inzichtelijk.

Ik zou ook altijd dan alleen bcc als optie aanbieden, maar veel software doet meer dan 1 ding. Dus wie weet was andere opties ook nodig.

Persoonlijk zou ik het heel knullig vinden als dit via Outlook of andere cliënt was veroorzaakt.

[phosporus]

hakken en spaanders zullen we maar zeggen.

[Cergorach]

Dat ligt er een beetje aan... Verstuurd via Outlook en Exchange Online, dan een foutje, maar iemand aan de admin zijde heeft ook de rate limit veranderd van 500 naar 800+. Als het een andere applicatie is, is er dan geen optie om het te blokkeren dat men het to of cc veld gebruikt als je naar externe klanten?

[Nyarlathotep]

Lijkt mij ook dat je dit af kan vangen. Een limiet van 10 man in de cc bijvoorbeeld. Zijn het er meer, dan wordt (automatisch) de bcc functie gebruikt. Of standaard bcc wanneer je externe email adressen gebruikt.
Overigens krijg je in elke moderne mail cliënt toch wel een waarschuwing als je zó veel adressen in het cc veld zet?

[Reactie gewijzigd door Nyarlathotep op 23 juli 2024 00:49]

[Cergorach]

Oh? Hoe doe je dat in Outlook? Hoe doe je dat in Exchange (Online)? Hoe doe je dat in Gmail?

"Lijkt me dat..." zijn hele foute woorden in de IT wereld...

[fifanoob]

kunnen ze het niet instellen op wat er achter @ staat? Dus als het allemaal @flevoziekenhuis.nl is dat er niet zoveel gebeurd, maar als er verschillende dingen staat achter de @ dat het systeem dan door heeft, verschillende soorten adressen, dit mag niet via cc want privacy blabla.

Hoeft volgens mij allemaal niet al te ingewikkeld te zijn? Maar kost wel geld, een keer sorry zeggen is goedkoper dus geen haast.

[Tc99m]

De vraag is dan ook niet zozeer hoe dit feitelijk heeft kunnen gebeuren, maar hoe het kan dat voor het informeren van 800 patiënten met de hand een e-mail is verzonden (waardoor de fout heeft kunnen gebeuren), terwijl er mailsystemen zijn die beter voor dit soort gevallen ingezet kunnen worden (juist om dit soort dingen te voorkomen). Waarschijnlijk weet niet iedereen die zich met communicatie richting patiënten bezighoudt dit, dus daar moet uitgezocht worden hoe dit voortaan beter kan.

[B64]

"Inmiddels loopt er een onderzoek over hoe het lek heeft kunnen ontstaan. "

In de text staat hebben niet als BCC opgestuurd? wat moet je daar nog aan onderzoeken, de persoon in charge heeft een fout gemaakt. Stres, drukte noem maar op.

- De ICT-afdeling die de mailserver en -clients niet zodanig heeft ingericht dat dit soort fouten, op deze schaal, worden afgevangen.
- Een privacy-officer die deze toch wel veelgemaakte fout niet in z'n checklist had staan bij het valideren van de ICT-systemen.

Het is zeker niet alleen de persoon die op 'Verzenden' heeft gedrukt die hier een steek heeft laten vallen

[Dynazap]

Gevalletje: Foutje, bedankt!

Medewerker wil een mail te sturen en zet de mailadressen niet in de BCC maar het andere balkje. Moet niet mogen kunnen.. maar mensen maken eenmaal fouten.

Daarnaast zijn er, zover in dit artikel duidelijk is, geen gevoelige persoonsgegevens gedeeld. Mooie wake-up call voor de IT-Security van het ziekenhuis en nu dus zorgen dat dit niet meer mogelijk is.

[Tc99m]

Nee, dit is niet 'foutje, bedankt'. Het is niet zozeer de fout van één persoon, maar de fout van een organisatie als geheel. Blijkbaar is het bij mensen die zich met patiëntencommunicatie bezig houden niet duidelijk dat er andere, meer geschikte tools zijn om dit soort mails mee te versturen.

Daarnaast is het feit dat iemand aan een MDL-aandoening wordt behandeld wel degelijk een gevoelig persoonsgegeven. Dat dit alleen is gedeeld met anderen die ook een MDL-aandoening hebben, doet daar niks aan af. Ik kan me goed voorstellen dat deze patiënten daar niet blij mee zijn als bijv. bekenden of een werkgever die informatie in handen krijgt.

[rlKoekie]

Als 1 van de 800 mensen die deze mail ontvangen heeft, kan ik bevestigen dat het wel degelijk een serieus lek is.
De email is speciaal gericht aan patiënten met een inflammatoire darmziekte (IBD). Meestal is dit ziekte van Crohn of Colitis Ulceroca, beiden chronische aandoeningen. Ik heb er zelf nooit een geheim van gemaakt dat ik patiënt ben, maar niet iedereen leeft hier zo open mee.
Misschien heb je een werkgever die minder begripvol is, of wil je een hypotheek kunnen afsluiten met overleidens risico verzekering zonder enorme boetes. Dan is het toch echt heel onprettig dat deze informatie nu op straat ligt.

[crazyboy01]

Blij om de begripvolle reacties hier te zien. Medewerker zal zich ontzettend rot voelen, dit is echt niet met opzet gebeurd en kan de beste overkomen - vind de stempel 'lek' ook best lastig. Het is natuurlijk wel een lek, maar vooral gewoon een fout.

[Verwijderd]

‘Lek’ bekt lekkerder dan ‘per ongeluk’

Inmiddels loopt er een onderzoek over hoe het lek heeft kunnen ontstaan.

Om maar geen gezichtsverlies te lijden, zeg maar

[Coach4All]

Ik vind het verbazend dat blijkbaar iemand makkelijker een lijst met namen en bijbehorende e-mailadressen uit een systeem trekt om te kunnen plakken in outlook dan een mailing via een daarvoor bedoelt systeem te doen.

[Mollos_]

In het verleden moesten wij ook mails via een reguliere mailapplicatie versturen. Op het moment dat we naar veel adressen moesten versturen was het de gewoonte om 4-ogen principe te hanteren, om te voorkomen dat dit soort dingen gebeuren. Doen wij sowieso bij gevoelige situaties.

Intussen gebruiken we een Hubspot voor het versturen van mails en werk je gewoon met ontvangers lijsten, waar iedereen een aparte mail met eigen aanhef ontvangt.

Het is niet ingewikkeld om een collega er bij te vragen voor het versturen, vooral als het om honderden adressen gaat. En zit je in je eentje, bel iemand erbij via teams voor je op de verzendknop drukt.

[Reactie gewijzigd door Mollos_ op 23 juli 2024 00:49]

[joop99]

Om dit soort fouten te voorkomen zijn er andere oplossingen als standaard email clients als Outlook e.d.
In mijn ogen kun je dit de medewerker niet verwijten, die dit met een normale email client en het gaat een keer fout.