Privégegevens nog steeds makkelijk te exporteren via GGD-systeem HPZone

Het GGD-systeem HPZone voor bron- en contact onderzoek is nog altijd niet goed beveiligd tegen het lekken van privégegevens. Uit onderzoek van NOS en Nieuwsuur blijkt dat er nog steeds makkelijk gegevens kunnen worden geëxporteerd als pdf.

Eerder deze week bleek uit onderzoek van RTL Nieuws dat er op grote schaal in privégegevens van Nederlanders wordt gehandeld uit de systemen van de GGD. Het gaat om zowel het systeem dat wordt gebruikt voor bron- en contactonderzoek, als het systeem waarin de privégegevens worden opgeslagen van iedereen die een coronatest doet. RTL ontdekte onder andere dat het mogelijk was voor werknemers om een export te maken van gegevens. Daarop zei de GGD dat het die exportfunctie snel had verwijderd uit het programma.

Nu meldt de NOS dat een week na deze ontdekking het alsnog mogelijk is om in het programma HPZone lijsten met persoonsgegevens uit te draaien. De exportfunctie waarmee in bulk data kan worden geëxporteerd is wel dichtgezet, maar via een printfunctie kunnen er nog steeds lijsten met gegevens als pdf worden opgeslagen.

In een reactie tegenover de NOS laat de GGD weten dat het klopt dat deze functie nog beschikbaar is, omdat deze nodig is voor het analyseren van data. Wel zegt de GGD bezig te zijn met strengere controles op het gebruik van deze functie. Eerder bleek juist ook dat er niet werd gelogd wie toegang tot de gegevens had.

Medewerkers bij de GGD kunnen via het systeem gevoelige gegevens uitdraaien zoals burgerservicenummers, adressen en medische gegevens. De gegevens konden maandenlang worden geëxporteerd door iedereen die toegang had tot deze systemen.

De GGD heeft aangegeven te willen stoppen met het gebruik van HPZone. Het programma moet worden vervangen door een veiliger portaal, dat beter geschikt is voor gebruik op grote schaal. Dat is pas eind maart klaar.

Door Robert Zomers

Redacteur

29-01-2021 • 20:52

122

Reacties (122)

122
113
57
15
0
45
Wijzig sortering
Ok, we gaan even naar een gemiddeld patient systeem. Geleverd door Chipsoft. ( HIX)
Ook daar kan je in wroeten en ploegen in patienten dossiers. Enigste verschil is dat ze ( de gebruikers) toch echt wel een VOG hebben en ten 2e gelogged worden bij het leven,

https://www.ad.nl/den-haa...lf-miljoen-euro~a332a557/

Desalniettemin is het mogelijk om data te ontfutselen op een level van verpleegster. Massaal exporteren van dat kan niet zomaar, maar ook hier is dit mogelijk, net op grote schaal, echter er wordt niet gewerkt met RBAC. Dus verpleger kan alvast patienten raadplegen in het systeem voordat die in een ziekenhuis is, oftewel, je kan nog als patient thuis zitten en men kan in je dossier kijken.

Je kan dit monitoren via volgjezorg.nl. Elke keer als je dossier wordt geraadpleegd krijg je een email.

https://persoonlijk.volgjezorg.nl/

[Reactie gewijzigd door PFY op 23 juli 2024 06:05]

Wat men op tweakers vaak vergeet dat het voor veel zorgmedewerkers ook belangrijk is dat er snelle toegang tot medische gegevens is. Het voorbereiden op een operatie, interdisciplinair overleg, een patiënt die opgenomen wordt. Allerlei zorgprofessionals kunnen zonder gedoe patiënten zoeken en de benodigde gegevens raadplegen (van labgegevens tot brieven van de huisarts aan het ziekenhuis). En ja dat is nodig voor een veilig verblijf....

Kan me zo voorstellen dat het voor contactonderzoek ook nodig is om gegevens bij de hand te hebben, allerlei complexe tweakers ict beperkingen zijn vaak onwerkbaar...
Zorgmedewerkers worden gescreend. Dit zijn haastig ingehuurde callcenter medewerkers. Een supermarkt laat savonds niet zijn kas opmaken door de 15 jarige vakkenvullers.
Ik gok alleen dat een 'gemiddeld' EPD-systeem niet geschikt of niet snel geschikt was voor bron- en contactonderzoek. Het doel van een EPD (dossiervoering op individueel niveau) is een andere dan voor bron- en contactonderzoek (nagaan besmettingsbronnen / netwerk / interactie).

Sterker nog ik denk dat menig EPD juist niet is ingericht om netwerkvariabelen makkelijk analyseerbaar te maken (omwille van privacy).
Ik heb nog nooit een mail gehad.
Ik wel hoor, mijn vrouw haalde mijn oogdruppels bij de apotheek. Paar minuten later een mail dat de plaatselijke apotheek mijn medicijnlijst heeft geraadpleegd. Tot nu toe werkt VJZ prima.
André Rouvoet zei:
GGD-voorzitter betuigt spijt: 'Systemen gaven ruimte voor datalek'

“Bovendien wordt voortaan continu gemonitord welke medewerkers gebruik maken van welke gegevens. Dat gebeurde tot nu toe alleen steekproefsgewijs.”
Als je het aangehaalde artikel helemaal leest, zie je dat hij helemaal niet belooft dat het datalek direct gedicht zal worden. Hij belooft enkel dat ‘voortaan’ wordt gemonitord wie de volgende is die er met data vandoor gaat.

Wat nog erger is:
"We zijn enorm geschrokken dat medewerkers zich hebben laten verleiden om gegevens naar buiten te brengen".
[...] Volgens Rouvoet is er niets met de meldingen gedaan, omdat het een bewuste keuze was om veel mensen toegang te geven tot alle gegevens.
Dus eigenlijk was het helemaal niet schrikken. Het was gewoon een ingecalculeerd risico dat ze er wel mee weg zouden komen. Met medeweten van het topmanagement.
Volgens Rouvoet is het onmogelijk om een systeem honderd procent veilig te maken: "Van elk systeem kan misbruik gemaakt worden door mensen die kwaad in de zin hebben."
Volgens diezelfde logica hoef je ‘s nachts ook niet je huis op slot te doen, want een inbreker komt toch wel binnen. Welterusten, beste GGD-voorzitter.

[Reactie gewijzigd door Tomatoman op 23 juli 2024 06:05]

Stel, het is maart 2020. Er is NU een systeem nodig. Wat doe je dan? Alles veilig maken en in 2021 releasen? Of de verantwoordelijkheid bij de mensen neerleggen.

Dit hadden ze achteraf natuurlijk wel moeten fixen (ergens in de zomer toen er meer rust in de tent was) maarja het is overheid dus langzaam.
Tuurlijk baal ik van het datalek maar ik kijk toch echt eerst de medewerkers aan die hun rechten misbruikt hebben. Er zat geen lek in de software he, alleen geen goed role based access model. Wat een drol ben je als je in 2020 dacht en onderdeel was van het corona register team: laat ik die data eens verkopen. Teleurstellend

Ik praat t niet goed maar het is een feit dat overheid en it geen match zijn, dat is helaas een geveven. Als je dan moet kiezen, kies je dan voor beschikbaarheid of risicio op datlek door medewerkers?
De call centers zijn pas in Juli/Augustus groter ingericht....
Het BCO onderzoek is pas ook ergens in die periode hervat.

Dus er was een paar maanden de tijd.
(Ze konden vast in die tijd wel iets verzinnen om printer onbruikbaar te maken, exports te verbieden etc.)
Maar je moet de risico's willen laten analyseren (daar is in Juni zelfs mee begonnen..)
En je moet er wat aan / mee willen doen.

M.i mag de GGD nu opdraaien voor de kosten van het voorzien van alle getroffenen van een nieuw BSN en alle bijbehorende papieren en plastic kaartjes.
Wel een puinhoop creeren maar het vervolgens niet oplossen?
Denk je echt dat het zo simpel was als de export en print functie te blokkeren?

Ik denk dat 90% dat nodig had om
Hun beroep uit te oefenen. Wil je dat fixen dan moet je dus beperkingen aanleggen zoals:
- medewerker koppelen aan regio en periode
- regio en periode weer koppelen aan dataset
- vliegende keeps moeten weer overal bij, daar weer iets anders voor verzinnen

IT is veilig als we gewoon alles uitzetten. Zo simpel is het helaas niet, het werkbaar en veilig maken kost echt heel veel werk
Call center medewerker die data moet kunnen exporteren en printen voor eigen gebruik?... dat zou nieuw zijn.
Natuurlijk moet de applicatie beter werken, maar de operatie had nog wat maatregelen kunnen nemen tegen misbruik.
Maar misschien kende het systeem nog geen verschil tussen een callcenter medewerker en een manager of een on site medewerker (die zag ik altijd met geprinte lijsten)

Misschien kon het systeem niet filteren op naam en moest een medewerker wel iedere keer export doen en met excel
Filteren?

Enz...
We weten het niet

Je kunt er alles van vinden maar hell bij een normaal bedrijf duurt de realisatie van zon informatiesysteem al jaren om het veilig te doen. Laat staan de overheid.
Het is makkelijk praten vanaf de zijlijn.
Nogmaals, ik praat het niet goed maar ik ken de overheid en het uberhaupt beschikbaar maken is voor ze al een mega prestatie.
En alle call center medewerkens en GGD interne medewerkens maken gebruik van een en dezelfde PC?...
Dat lijkt me onwaarschijnlijk..., het zou wel verklaren waarom ik een week op m'n uitslag moest wachten...
(het virus had helaas niet het geduld om op die uitslag te wachten, ik was al over het dieptepunt van de ziekte heen toen ik gebeld werd over de uitslag, de koorts was alweer van 40 gezakt naar een 38.9).
Het kan gewoon een inrichtings eis voor een werkstation zijn vast een windows systeem, dan is een GPO toch niet al te ingewikkeld.

[Reactie gewijzigd door tweaknico op 23 juli 2024 06:05]

Ik snap echt niet wat een pc of
Gpo hiermee te maken heeft

Lees dit maar eens
Verwijderd in 'nieuws: GGD gaat lekke HPZone-software vervangen'

Hier lees je zelfs dat er gewoon audit logging en rollen per regio inzitten

Maar lets agree to disagree :)

[Reactie gewijzigd door laurens0619 op 23 juli 2024 06:05]

Maar zijn verhaal gaat op verschillende punten mank omtrent de realiteit van de testcentra en de callcenters. Er was helemaal geen regionale beperking. Was het ene callcenter te druk en had een andere regio capaciteit over dan werd die capaciteit ingezet voor die andere regio en daarom hadden al die callcenters continue toegang tot alle gegevens op landelijk niveau.

Daarnaast zijn er al sinds een tijdje mensen die melding hebben gemaakt van het benaderd te zijn door oplichters een dag nadat zij hun gegevens aan het testcentra hebben afgestaan, als er logging zou zijn dan zou men weten wie die gegevens heeft opgevraagd, maar men heeft beenenkel idee omtrent wie wat heeft opgevraagd, die logging is er dus niet. Misschien wel voor zijn systeem maar niet voor het systeem zoals dat nu wordt gebruikt voor de testcentra en contactonderzoeken.
Een systeem is niet alleen software, en hardware, het is ook de omgeving waarin het draait, en ook de mensen die ermee werken. onder verantwoording van de organisatie die het gebruikt.

Dus als de software niet is ingericht is dat nog steeds niet goed. Als de logging is ingericht maar nooit gecontroleerd wordt is het ook niet goed, ....
In het andere topic van gisteren stond een reactie van een interne medewerker van een GGD dat 'even snel' ingehuurde callcenter medewerkers in een werkweek soms iedere dag voor een andere GGD(regio) moesten werken.
Je kan dat afschuiven op het ICT-technische systeem, maar volgens mij is er geen beginnen aan om dit applicatie technisch gezien te managen met de druk die erachter zat.

Edit:
Voor de duidelijkheid, ze hebben gewoon gekozen voor de manier waarop gebruikers van het systeem tegen zo min mogelijk beperkingen zouden aanlopen functioneel gezien.
Maar natuurlijk had het veel beter gekund.
Ze hadden in februari al moeten beginnen met het aannemen van personeel, want toen was al zo goed als zeker dat het virus heel de wereld ging treffen.
Duitsland was dat b.v. al in een veel vroeger stadium aan het doen.

Maar zoals het vaak gaat krijgt een ICT systeem of organisatie de kritiek, terwijl bijna altijd op een ander niveau, in ern vroeger stadium fout gaat.

[Reactie gewijzigd door YoMarK op 23 juli 2024 06:05]

Voor de duidelijkheid, ze hebben gewoon gekozen voor de manier waarop gebruikers van het systeem tegen zo min mogelijk beperkingen zouden aanlopen functioneel gezien.
Dat is dus tegen alle richtlijnen voor informatie beveiliging en wettelijke eisen die hieraan gesteld worden in.
Klopt helemaal, maar het is iets anders dan dat 'een programma niet deugt' of 'er geen kennis van ICT aanwezig is'.
Dit is een bestuurlijke beslissing geweest. Dat is niet wat jij letterlijk zegt overigens hoor, maar ook huer op tweakers.net lijken veel ICT-ers te denken dat dit op technisch vlak fout gelopen is.
Uiteindelijk zijn die richlijnen leuk, maar dit gaat over zoveel laagjes heen, dat kritieken vanuit de uitvoerende technische laag, nooit de management laag bereikt die e.e.a. door probeert te drukken. Daar zorgt men wel voor, zodat ze altijd de 'dit wist ik niet' kaart kunnen spelen. En dus is de kritiek in de media 'de ICT is weer niet op orde bij de overheid'. En dat is in 90% van de gevallen onzin. Gaat overigens niet veranderen met een partij als de VVD aan het roer.

[Reactie gewijzigd door YoMarK op 23 juli 2024 06:05]

Het systeem (Applicatie, Omgeving, inzet beveiliging, inzet auditing, gebruikers, beheerders) is zodanig ingericht dat een lek onvermijdelijk is.
Dat is idd. een bestuurlijke beslissing mag je hopen (en niet een luie beheersclub).
Het kan zijn dat die tool helemaal niet geschikt is voor deze manier van inzet, maar ook dat is een keuze.
Duidelijk is dat, vermoedelijk bewust, de verkeerde keuzen gemaakt zijn.

Ik verwacht dat er bij vrijwel geen enkele partij, zeker die nu in de 2e & 1e kamer zitten, hier iets aan gaan veranderen. Het is een te makkelijke uitweg als het elders knijp loopt.
Wanneer je systeem niet normaal ingericht is kun je toch beter aan de cliënt kant monitoren? Een log bijhouden van save/print acties lijkt mij niet heel lastig. Wanneer je afwijkt van standaard screen monitoring starten. Gezien de gevoeligheid van data lijkt me dat juridisch ook geen probleem.
Dat is een kwestie van jet juiste systeem kiezen. Er zijn echt wel systemen waar je heel gedetailleerd in kan stellen wie bij welke informatie en functies mag. Ik werk bij een bedrijf waar we zo'n systeem aanbieden en dit is letterlijk een peulenschilletje om goed te configureren voor een ervaren consultant. Zoiets aanpassen kost maximaal een aantal uren in plaats van maanden.
Niet alles is simpel, maar logging aanbrengen en een melding af laten gaan als een medewerker van niveau calldesk wel erg veel gegevens opvraagt is simpel. Het is juist de combinatie van iedereen heeft maar overal toegang toe en we houden helemaal niet bij wie wat doet die dodelijk is voor gegevensbescherming. Dat je toestaat dat mensen een DB leegtrekken en wegschrijven naar een usb stickie zonder dat er ook maar enige vorm van terugkijken mogelijk is, is in mijn ogen gewoon crimineel gedrag en vervolging voor uitlokking en verwaarlozing beschermplicht zou zeker op zijn plaats zijn.
Wat ik begrijp is dat hpzone een (extern) zorginformatiesysteem is wat ze al
Jaren gebruikten

Dat iets programmeertechnisch simpel
Is te realiseren betekent niet dat het echt zo simpel is. Misschien was het een zis op een oude versie waar de vendor geen updates meer kon aanbrengen en de enige optie was naar een modern systeem te migreren (wat ze nu doen)?

Maar als ik het lees dan zat de logging er wel in, zo hebben ze
Denk ik die 2 mensen opgepakt?
Zo hadden alleen geen geautomatiseerde anomaly/misbruik monitoring

https://www.volkskrant.nl...riminele-handen~b7f17bea/

[Reactie gewijzigd door laurens0619 op 23 juli 2024 06:05]

Even heel simpel gedacht. Een gegevensopvraag is niets meer of minder dan een query gemaakt vanuit een bepaald User-ID, ik zeg niet dat het in een uurtje is gefixed, maar hoe moeilijk kan het zijn om die query en User-ID ook weg te schrijven naar een log. Hoe je die log uitleest e.d. daar kun je later mee aan de slag, maar om te draaien met een systeem met gevoelige en persoonlijke data waar duizenden mensen waarvan velen ook nog een keer nieuw uit de bakken van de uitzendbureau's komen onbeperkt toegang tot hebben, en zonder dat er voor aanvang een VOG overlegt dient te worden en zonder dat er ook maar enige vorm van registratie plaatsvindt omtrent wie wat opvraagt en had men het even later toegevoegd dan had ik nog kunnen geloven in het riedeltje van haast, haast, haast.. Maar nu heeft men bijna een jaar gedraaid, waarschuwingen genegeerd en zoals gewoonlijk grijpt men pas in als het op teletekst staat. Verantwoordelijken voor dit gebeuren mogen om mij voor de rechtbank het moet maar een keer afgelopen zijn met het "ach, wat boeit het, we komen er toch wel mee weg als het fout gaat en in de tussentijdhouden we de hand lekker op de knip."
Met als toevoeging dat het ook nog eens direct om heel persoonlijke gegevens ging, niet enkel een telefoon registratie, nee: volledige identiteitsgegevens mét bsn.
Er schijnt helemaal niemand opgepakt te zijn: https://twitter.com/danielverlaan/status/1355157620571705349
Echt onvoorstelbaar hoe dit zich ontwikkeld
Het is wat vaag maar ik geloof dat er wel 2 mensen zijn opgepakt maar de “meerdere erna” dat dat niet klopt
https://nos.nl/l/2365961
Er zijn wel twee jongens voor opgepakt, echter ging het rond dat er daarna nog meer mensen zijn opgepakt, maar dat is blijkbaar dus onjuist.
Nee misschien was het vervelend geweest voor de medewerkers om de print functie niet meer te hebben en dat dat dan een keuze was die ze hebben gemaakt in de crisis tijd. Ze hadden wel het MINIMALE kunnen doen door te loggen welke medewerker welke indexes inziet om op die manier op zijn minst schade te voorkomen.
Precies, en anders maakt men wel een print screen, als dat niet kan foto met mobiel. Mobieltjes kun je wel verbieden. Een systeem volledig dicht timmeren kan wel maar kost tijd.

Best practices bestaan al, ook hiervoor. Maar als een manager geen goede training heeft gehad..

Dit was allemaal te voorkomen geweest met een betere implementatie, Zoals PCI DSS maar dan voor BSN en medische gegevens. Systemen en processen daarvoor bestaan al, dus het is niet het wiel opnieuw uitvinden.
Precies. Leuk hoor dat alles gelogd wordt enz. Dat print to printer en pdf uitgezet is en wordt. Echter als zo’n medewerker echt kwaad wil, kan je met je mobieltje foto’s maken van het scherm en met een text analyzer alles nog eenvoudig omzetten naar een spreadsheet ook.

De kern zit bij de poort. Fatsoenlijk screenen etc van mensen die met de data werken. Ook dan voorkom je geen lekken maar het is wel de eerste stap.

Een VOG is sowieso een wassen neus.
De kosten verhalen lijkt me een goed idee, maar pak dan wel de werkelijke dader aan. Dat zijn en blijven toch echt de medewerkers die deze data verkocht hebben. En de personen/instanties die deze data aangekocht hebben. Maak daar werk van én zorg dat de ICT op orde komt.
Ik ben het helemaal met je eens, maar als de personen niet identificeerbaar zijn door gebrekkige keuzen in het besluitvormingstraject rondom de opdrachten voor het inrichten van de systemen op deze manier dan zijn die opdrachtgevers ook mede aansprakelijk.
"gelegenheid bieden", "onvoldoende toezicht"...

[Reactie gewijzigd door tweaknico op 23 juli 2024 06:05]

Dus er zat wel een lek in.
Er zat geen lek in de software he, alleen geen goed role based access model.
Niet alle lekken hoeven software-matig te zijn, social engineering is het makkelijkste lek dat er te vinden valt. Het feit dat er geen consequenties en/of monitoring op zat zegt al genoeg..
Fair enough :)

Ik doelde meer op een lek dat mensen die toegang hadden tot het systeem toch bij de data konden. Een open nosql database op een amazon ip (om maar iets te noemen)
mensen maken deel uit van het systeem.
Natuurlijk zijn die misbuikende medewerkers laakbaar en moeten keihard worden gestraft.

Maar laat die top van de GGD hier ook voor boeten. Volgens Rouvoet waren ze direct al op de hoogte van dit mogelijke privacylek en hebben ze er tot nu toe niets mee gedaan. Ja, pas als journalisten naar buiten komen met bewijs. Dit is echt schandalig, crisis of niet.
Stel, het is maart 2020. Er is NU een systeem nodig.
Dan hebben ze al gefaald.

Vrijwel alle gevraagde functionaliteit rond corona valt onder het standaard takenpakket van de GGDs.

Er moest geen nieuw systeem komen maar een schaalvergroting op de bestaande systemen. Bestaande systemen die kennelijk standaard al zo lek als een mandje waren.
Een werkend, goed opgezet role based acces model is onderdeel van een isae3402 verklaring die verplicht is voor instanties zoals de ggd. Volgens mij is hier veel meer mis gegaan, als eerste een bestuur waar geen enkele bestuurder in zit die IT snapt. Ten tweede een AP die onderbezet en zwaar bureaucratisch is.
Uit interesse, wordt dit ook geauditeerd? En door wie of wat?
Ja, jaarlijks door bedrijven zoals Kpmg, E&Y etc.
Dat systeem had al voor corona er moeten zijn!
Stel, het is maart 2020. Er is NU een systeem nodig. Wat doe je dan? Alles veilig maken en in 2021 releasen? Of de verantwoordelijkheid bij de mensen neerleggen.
Alles veilig maken en in maart 2020 lanceren. We moeten het niet spannender maken dan het is: HPZone is gewoon een grote database met allemaal velden met persoonsgegevens. Afhankelijk van de persoon in kwestie, kun je 1 of meerdere velden verbergen. Of je kunt delen van de informatie in die velden verbergen. Het toevoegen van Role Based Access zou niet meer dan 2 of 3 dagen werk max moeten zijn. Het verbergen van velden die helemaal niet relevant zijn, is minder dan een paar uur werk.

Prutserij van de hoogste plank dit.
Ja, maar wat nu als men het er doordrukt dat iedere dag een ander clupje externe callcentrum medewerkers actief is voor een GGD(regio) en de volgende dag zijn die weer werkzaam voor een ander GGD.
Ik ken het pakket HPZone verder niet, maar kan me niet voorstellen dat je het dan nog 'strak' dichtgetimmerd krijgt. Oo een gegeven moment kan dus iedereen overal bij.

[Reactie gewijzigd door YoMarK op 23 juli 2024 06:05]

Dat maakt verder niet uit. Als ik jou vervang voor een ander, dan geef ik die ander gewoon dezelfde rechten mee. Dat is RBAC. Een op een rol gebaseerde rechten.
Stel, het is maart 2020. Er is NU een systeem nodig. Wat doe je dan? Alles veilig maken en in 2021 releasen? Of de verantwoordelijkheid bij de mensen neerleggen.
Op zo'n moment heb je ballen en neem je ongeacht de kosten een partij in de arm die gespecialiseerd is in het opzetten van CRM en database systemen met granulaire data-toegang. Zij zullen met zeer grote waarschijnlijkheid binnen no-time een baseline installatie van hun product uitgerold kunnen krijgen welke vele malen veiliger is dan het bestaande tyfus-oude systeem waarvan feitelijk al jaren bekend is dat het achterhaald is; onveilig is; en nooit voor deze doeleinden bedoeld was.

Je enige probleem op dat moment is gebruikers trainen met het nieuwe systeem. Maar gezien we het hier hebben over een situatie waar er opgeschaald moet worden zodat het aantal gebruikers ettelijke malen compleet over de kop gaat en wellicht zelfs verhonderdvoudigd wordt, moet er toch training plaatsvinden en vallen de kosten voor de oudere, bestaande poel gebruikers 'bij te trainen' ook in het niet daarbij.


Ook de aansluiting op 'tig achterliggende processen is hierbij niet noodzakelijk een probleem. Zo'n nieuw systeem kan tijdelijk in batches updates ter verwerking aanbieden aan het oude systeem, waardoor alle achterliggende processen via het oude systeem nog kunnen blijven lopen terwijl deze koppelingen mondjes-mate over langere termijn overgezet worden.

Zet je dat goed op, dan garandeer je daarmee dat al het extra ingestroomd call-center personeel niet bij die oude systemen hoeft te kunnen maar enkel met het nieuwe - veilige - systeem te maken krijgt.


Maar goed; dat is de oplossing die je in zo'n situatie van een op elkaar ingespeelde snel-schakelende kliek praktijk-experts in de IT krijgt. En niet wat je van een stelletje ongerichte middle-managers zult krijgen. Zoals gewoonlijk is de beste methode om in een crisis-situatie je IT te verneuken, de middle-managers aan het stuur te zetten. (Of nog erger: uit te breiden en aan het stuur te zetten.)

[Reactie gewijzigd door R4gnax op 23 juli 2024 06:05]

Ach laten we een ict bedrijf een blanco check geven zonder aanbesteding wat zou er (met ons belastinggeld) mis kunnen gaan? U vraagt wij graaien?
Dit soort systemen moet je op de plank hebben liggen voor het geval dat. Dat geldt voor zo ongeveer alles aan deze crisis. Nederland heeft het niet of heel laat pas geregeld allemaal.
Nee dan release je niet in 2021. Wat je wel eens zou moeten doen is binnen de zorg ophouden met het vastleggen van allerlei gegevens die je totaal niet nodig hebt in het stuk waar je mee bezig bent.
- bsn (hoezo heb je die uberhaupt nodig maar in dit geval zeker niet)
- naam
- geboortedatum

Het enige wat je nodig hebt is een telefoonnummer en eventueel een voornaam, misschien een e-mail adres. Je moet mensen kunnen bellen als je een bron/contact onderzoek doet of het doorgeven van een positieve uitslag.
Je kunt de uitslag ook online via digid inzien maar daar heb je ook geen persoongegevens voor nodig, dit zit met een unieke identifier gekoppeld welke aan de code zit die je krijgt bij het maken van je afspraak. Dat is het enige gegeven wat je in beginsel nodig hebt.

Wat mij betreft schend de zorg dagelijks de AVG...
Dit. Dit wekt helemaal geen vertrouwen dat het 1. opgelost wordt of 2. in de toekomst aangepast wordt
Ik laat me voorlopig niet testen, dat is wel duidelijk. Chapeau!
Dit zijn mensen die nooit bloeden voor hun blunders. Simpel weggepromoveerd naar andere topbaan. One for all, all for one. En de burger..... euh, dat is de financierder

Als Rutte, na toeslagen affaire verplicht 5 jaar RWW kreeg en in schilderswijk moest wonen en nooit meer ambtenaar mocht worden, dan was het snel over met dit soort fratsen.

[Reactie gewijzigd door gepebril op 23 juli 2024 06:05]

Sorry hoor maar hoe kun je nu schrikken dat sommige medewerkers crimineel zijn? Wat is dat voor naïviteit.
29 jan zat Andre bij Nieuwsuur.

Wat ik begrepen heb uit zijn toelichting is dat het systeem al lang gebruikt werd, en met de crisis is opgeschaald. Kortom, die toegang is nooit goed geregeld geweest.

Voor het doorbellen van testuitslagen, heeft een medewerker nauwelijks toegang nodig. Er is bekend welke mensen gebeld moeten worden, het systeem belt die persoon. Vervolgens krijgt de medewerker te zien wat hij of zij moet zeggen.

Voor BCO, is wel iets meer toegang nodig. Daar moet je ook gegevens kunnen invoeren.
Maar verder dan naam, geboortedatum, telefoonnummer en de cijfers van de postcode hoeft dat niet te gaan.

Voor het vrij doorzoeken van een database zie ik geen enkele use-case.

Helaas gaat in dit geval ook op, dat een bedrijf 3 services levert:
1. Snel
2. Goed
3. Goedkoop
Je kunt er maar twee kiezen.

[Reactie gewijzigd door sircampalot op 23 juli 2024 06:05]

Het aantal applicaties waar ik op een fatsoenlijk detailniveau de toegang kan regelen is werkelijk waar op 1 hand te tellen. Ben al blij als ik meerdere users kan maken en die enigszins een beperkte toegang kan geven.

Vanuit een AVG perspectief kan 95% van de software zo rechtstreeks naar /dev/null worden verplaatst.
Daar gaat het dus al mis in die opmerking. Er zou moeten staan. Medewerkers krijgen alleen toegang tot de voor hun noodzakelijke data. Elke handeling wordt vervolgens gelogd en gemonitord.

Voor belangrijke personen in de database moet de toegang dan maar via een aparte afdeling. Gelijk zoals het FIOD deel nu ook is afgeschermd van de rest van de BD.
eh ze analyseren data met losse pdf-jes? geen audit trail? lekker bezig.
dichtzetten die hap. kwaadwillende gebruikers verzinnen toch wel wat. maar maak ze het niet te makkelijk.
#privacybydesign
Is het een keer makkelijk om een goede data export te maken, is het nog niet goed.
Dat is ook iets wat ik me afvraag: ik kan me voorstellen dat dit soort exports juist nodig zijn om het werk te kunnen doen (werklijsten van na te bellen mensen, etc..). Volgens mij zit het probleem eerder in het borgen van de integriteit van de mensen dan in de techniek.
Een export kan wel nodig zijn, maar export voor analyses dienen geaggregeerd te zijn, of als het over individuele data gaat geanonimiseerd. Ook als het niet mogelijk is te anonimiseren dient data minimalisatie toegepast te worden (je moet kunnen bewijzen dat BSN in de export nodig is). Iedere EPD leverancier in Nederland moet hier gewoon aan voldoen (AVG +NEN7510-7513). Mensen die werken met deze data moeten gescreend zijn. Maar puur vertrouwen op integriteit is nooit genoeg en niet meer van deze tijd. Daarom is het zo stuitend dat dit (in house ontwikkelde?) systeem van de GGD hier niet aan voldoet!
Ik deel je mening dat je als organisatie dataminimalisatie moet toepassen waar mogelijk. Maar, mijn punt is dat de informatie wel eens nodig kan zijn. Iedereen valt wel over dat dat soort exports niet mogelijk zouden moeten zijn, maar ik vraag me dus af wat de rol van die functie is. Dat BSN is bijvoorbeeld wettelijk verplicht als men op basis van die Excel de etiketten print voor de buisjes die naar een laboratorium gaan (want Wet op de Geneeskundige BehandelOvereenkomst en de wet BSN in de Zorg). Zonder dat soort dingen te weten is het lastig oordelen of zo'n functie noodzakelijk is.

Mensen roepen vrij makkelijk dat iets niet zou moeten mogen (geen specifiek verwijt naar wie dan ook), maar mijn ervaring is dat functies niet zomaar ontstaan, en dat er dus vaak ergens iemand een reden aannemelijk heeft weten te maken. Of het een goede reden is, en of deze nog steeds zo handig is weet ik niet, maar functies ontstaan niet spontaan.
Ik hoop toch echt dat op de buisjes een TEST-NUMMER staat en geen BSN.
En dat de applicatie de test-id's en de BSN's in een database koppelt.
Ik hoop toch echt dat op de buisjes een TEST-NUMMER staat en geen BSN.
Dat hoop ik vanuit privacy ook. Vanuit mijn werk weet ik dat in medische laboratoria dat ook de normale opzet is. Maar ik weet zelf eerlijk gezegd niet hoe men het hier heeft opgezet. Die hele test-infrastructuur is nogal uit de grond gestampt volgens mij....
Het klopt helaas dat we nu eenmaal verplicht BSN als identifier in de zorg gebruiken. Daar kan de GGD niets aan doen.

Dat deze functionaliteit niet zo handig is moge duidelijk zijn, het is zelfs zeer schadelijk gebleken. Je observatie dat functionaliteit niet zomaar ontstaat deel ik niet: het kost veel werk om per data view te bepalen welke velden getoond mogen worden.

Ik ben me bewust dat ik kritiek heb zonder te weten of alle geruchten waar zijn. Volgens mij heeft de GGD echter toegegeven dat audit logging niet geïmplementeerd is (dit is in ieder geval verplicht), verder is bewezen dat bulk exports gemaakt zijn met BSN (ik kan geen enkele usecase bedenken waarbij dit nodig is door een andere rol dan database admin). Als iemand met ervaring in EPD ontwikkeling denk ik dan dat er ofwel archaïsche software gebruikt wordt, of dat de regels en normen die terecht opgelegd worden aan private bedrijven niet toegepast worden door de GGD.
functies ontstaan niet spontaan

Nee, klopt, maar soms wel onbedoeld
Precies!
Slechts een kleine minderheid van de GGD heeft ivm zijn/haar functie toegang nodig voor rapportages en data analyse. Daarbij zijn privacy gevoelige gegevens niet nodig.
De “gewone” GGD medewerkers die afspraken inplannen voor Corona test afspraken en vaccinatie afspraken hebben niets te maken met data analyse en rapportages.
Het hele systeem lijkt steeds meer op broddelwerk en straalt onkunde uit.
Voor het nabellen van mensen heb je geen BSN van de geteste persoon nodig; dat kan prima met uitsluitend NAW-gegevens. Daarnaast is het (nog steeds) de vraag of bron- en contactonderzoek die meerwaarde heeft zoals wordt beweert.
Daarnaast is de software die de GGD thans gebruikt niet een EPD, maar slechts een standaard commercieel databaseprogramma. Het opvragen van BSN's is derhalve zeer waarschijnlijk ook nog eens onwettig.
Daarnaast is het (nog steeds) de vraag of bron- en contactonderzoek die meerwaarde heeft zoals wordt beweert.
Voor zover ik het begrijp wordt dit niet alleen voor Corona gebruikt, maar ook voor andere virussen. Dan kan het wel effectief zijn, en waarom van systeem wisselen (met kinderziektes) als je een enorme uitbraak hebt?
Daarnaast is de software die de GGD thans gebruikt niet een EPD, maar slechts een standaard commercieel databaseprogramma. Het opvragen van BSN's is derhalve zeer waarschijnlijk ook nog eens onwettig.
Die moet je eens beter uitleggen want ik snap je niet. Ten eerste: als je zorgverlener patientinformatie in een database duwt, dan is het per definitie een EPD. Je kunt er allerlei vraagtekens bij beveiliging en functionaliteit stellen, maar de term EPD is zeker niet voorbehouden aan de HIS en ZIS leveranciers in Nederland.

De wet BSN op de Zorg slaat niet alleen op EPD's, maar op alle zorgcommunicatie rondom een patient. Als ik de wetstekst er op nasla (zie https://wetten.overheid.nl/BWBR0023864/2020-07-01) dan valt dit gewoon bikkelhard onder deze wet (specifieker, men is expliciet genoemd in Artikel 6d van de wet Publieke Gezondheid). En daarmee is men wettelijk verplicht het BSN te gebruiken.....

[Reactie gewijzigd door J_van_Ekris op 23 juli 2024 06:05]

Voor zover mij bekend zijn de door de GGD gebruikte softwareprogramma's niet gemaakt/geschikt voor patiënteninformatie. De systemen in huisarts- en tandartspraktijken, ziekenhuizen enz. zijn dat wel, en dienen bovendien aan strenge eisen gebonden. De toegang tot die informatie is dikwijls ook nog weer getrapt; niet elke zorgmedewerker is bevoegd om het gehele dossier te zien. Bij de GGD is dat in dit geval wel anders, iedereen kon en kan nog steeds alle informatie zien.
De GGD heeft overigens zelf ook aangegeven dat de door hun gebruikte programmatuur niet geschikt is voor hun werk, maar dat er (blijkbaar) niets beters voorhanden is. Wat overigens geen excuus dat men er voor had moeten zorgen dat deze excessen niet voorkomen. Niet elke database waar je zorginformatie instopt is daarmede verandert in een EPD. Zoiets toch doen is niet toegestaan.
Dat de wet BSN in de Zorg op alle zorgcommunicatie rondom een patiënt van toepassing is, wil nog niet zeggen dat je die informatie zonder meer in elk willekeurig systeem mag opslaan. Dat mag alleen in toegelaten systemen. Omdat de programmatuur van de GGD daaraan (ook dus volgens henzelf) niet voldoet is deze instantie m.i. in overtreding.
Bronnen en contactonderzoek kan heel nuttig zijn. Bij een uitbraak hier in de buurt bv viel het terug te voeren op een balletleraar. Toen hebben ze z'n leerlingen geïnformeerd, en een flink gedeelte bleek via hem Corona te hebben opgelopen.
Waarom moet je iets naar een ander systeem kunnen exporteren terwijl het binnen je bedrijf blijft?
Dat wil dus gewoon zeggen dat het huidige systeem gebrekig is
Omdat geen enkel systeem alles kan? Ik heb vaak genoeg te maken met systemen waarbij data uitgewisseld moet worden omdat het ene systeem de bron is en het andere systeem iets moet met die data (tonen aan gebruikers, berekeningen op uitvoeren, noem maar op). Dat betekent niet meteen dat 1 van die systemen gebrekkig is.
Je gaat me niet zeggen dat je per se Excel nodig hebt voor die data
Ieder simpel programma kan die platte data weergeven
Er hoeft namelijk geen analyse gemaakt te worden
Bovendien blijkt het wel dat dat niet nodig is, aangezien die functie al geblokkeerd is
Het enige wat nog mogelijk is, is het printen
Dat is toch compleet nutteloos?
Je gaat me niet zeggen dat je per se Excel nodig hebt voor die data
Need I say more: https://www.theguardian.c...00-covid-tests-in-england

Soms is Excel gewoon een belangrijk element in een keten. Hoe stupide ook. Als de Britten zo stom zijn, waarom zouden wij dan slimmer zijn?
Beide moeten goed zitten, de mensen moeten integer zijn, maar het systeem moet er ook van uit gaan dat mensen dat niet zijn (genoeg voorbeelden van) en dus zou niet iedereen een volledige export moeten kunnen maken. En integriteit kan door het systeem afgedwongen worden, als medewerkers weten dat hun acties bijgehouden worden en er echt sancties op foutief gedrag staan, dan laten mensen het ook sneller uit hun hoofd om misbruik te maken.

Bedenk ook, dat zelfs als alle werknemers integer zouden zijn, kwaadwillenden van buiten dan nog steeds proberen in te breken en met de rechten van werknemers acties uit kunnen voeren als dat lukt. Nu zijn rechten van normale werknemers niet zo heel boeiend, maar je kan er ook vanuit gaan dat die accounts minder goed beveiligd zijn.

[Reactie gewijzigd door Transportman op 23 juli 2024 06:05]

Binnen HPZone is het mogelijk direct op het dashboard te zien welke cases nog aandacht behoeven. Dus een export functie is voor dat niet per se nodig. Wel handig.
Ik zal wel informatie missen :P maar hoezo is het hebben van een printer functie met PDF noodzakelijk voor het analyseren van data?
Ik denk dat ze niet zo snel een beter argument konden verzinnen, maar het slaat natuurlijk nergens op. |:(

Ik probeer mij een voorstelling te maken hoe je de data analyseert op papier nadat je alles uitgeprint hebt. Daar snap ik niets van, maar ik ben dan ook geen data analist. :?
Stapel papier. Potlood en dan turven. En alle bsn over schrijven denk ik. En elke medewerker is blijkbaar analist (want die export functie).
Nee, dit argument slaat echt met een tang op een varken als je het mij vraagt. Ik ben ook geen analist maar je voelt op je klompen aan dat je meer iets kunt met een export van een csv dan met een stapel printjes. En dat die analist helemaal geen bsn nodig heeft voor welke analyse dan ook (behalve als je wilt weten hoevaak de zelfde persoon is geweest; maar zelfs dat kun je privacy vriendelijker oplossen).
De echte vraag die we moeten stellen is waat mensen zodadelijk kunnen aankloppen als hun zeer gevoelige data misbruikt word.
Dat kan ook jaren later zijn als iedereen dit alweer vergeten is. Je weet dus nooit waar je data gelekt is.

Tenzij ze dan het e-mailadres gebruiken wat ik aan de GGD gegeven heb, want die was uniek. 8-)
En er is op korte termijn wel een veilig stukje software beschikbaar? inclusief audit verslag?
De eerste keer dat hier berichtgeving over en aandacht voor was: super.

Nu zijn we alleen op het punt dat het een beetje te veel door blijft drammen. Uiteindelijk weten we dat het systeem niet kan voorkomen dat medewerkers een onbeperkt aantal persoonskaarten in kunnen zien, dus of ze die nu met honderd tegelijk met een Print knop kunnen opslaan als PDF of met een macro van elk scherm een screenshot kunnen nemen en zo alle gegevens er uit schrapen maakt weinig verschil meer.

Alle aandacht die nu besteed wordt om die printfunctie uit te zetten, zorgt dat de aanpak van het échte probleem alleen maar vooruit wordt geschoven.

Een simpel in te voeren en effectieve oplossing is om het aantal verzoeken dat een gebruiker richting de database mag doen, te limiteren op een bepaald aantal per dag. Hetzelfde voor queries waarmee (vaak waarschijnlijk terecht) rapporten over meerdere personen uitgedraaid kunnen worden. Gebruikers die daadwerkelijk vaker gegevens op moeten zoeken kunnen dan op een whitelist komen met een hoger "tegoed".

[Reactie gewijzigd door Skit3000 op 23 juli 2024 06:05]

...laat de GGD weten dat het klopt dat deze functie nog beschikbaar is, omdat deze nodig is voor het analyseren van data.
ja ja, datamining en analyse doe je met PDF bestanden.
ik lees veel tenenkrommende redenaties van de GGD om het probleem te bagatelliseren.

waarom niet: eerlijk toegeven dat het mis is gegaan -> systeem uitzetten -> chef IT ontslaan
Ze zeiden er niet bij wie de datamining moest gaan doen... dan kan ook uitbesteed worden, blijkbaar hadden een paar call-center medewerkens een paar contacten die dat wel even konden doen voor "weinig".
Als ik mijn zaakjes niet goed op orde heb krijg ik boetes van heb ik jou daar. En hier zegt men gewoon, tsja.

Op dit item kan niet meer gereageerd worden.