Albert Schweitzer-ziekenhuis wiste per ongeluk bestanden van 200.000 patiënten

Het Albert Schweitzer-ziekenhuis, met vestigingen in Dordrecht, Sliedrecht en Zwijndrecht, heeft per ongeluk 513.000 oude digitale bestanden gewist uit de dossiers van 212.000 patiënten door deze te overschrijven met nieuwe bestanden.

Dat schrijft het ziekenhuis in een brief aan patiënten, die Tweaker equit1986 op GOT zette. Daarin is te lezen dat het ziekenhuis de oude bestanden niet meer kan terughalen. De documenten hadden twintig jaar bewaard moeten blijven, maar werden per ongeluk overschreven door nieuwe bestanden, doordat bestandsnamen werden gebruikt die ook gebruikt werden voor de oude bestanden in de elektronische patiëntendossiers. Het gaat om onder meer verwijsbrieven, onderzoeksresultaten en aantekeningen van de behandelaar.

Het gaat om onder meer verwijsbrieven en onderzoeksresultaten van voor september 2017. De bestanden zijn oud en werden in de regel niet meer gebruikt. Bij de invoering van het EPD werden de oude papieren documenten gescand en opgeslagen in een digitaal archief. Het ging hierbij om bestanden waarvan de arts dacht dat ze nooit meer nodig zouden zijn en die daarom niet toegevoegd werden aan het EPD. De papieren documenten werden destijds vernietigd. Het gaat om bestanden van voor september 2017.

Bestandsnamen overschreven

Sinds 2017 worden nieuwe, actuele documenten digitaal toegevoegd aan het EPD, legt het ziekenhuis uit. Daarbij is een fout gemaakt, waardoor tussen november 2020 en oktober 2021 de oude, gearchiveerde bestanden werden overschreven door nieuwe bestanden die door artsen werden toegevoegd. De fout kwam aan het licht toen een behandelaar de historische gegevens van een patiënt wilde inzien, maar een nieuwer document tegenkwam. Dit bleek in de plaats gekomen te zijn van de oude scan.

Het ziekenhuis is samen met EPD-leverancier Chipsoft een onderzoek gestart naar de oorzaak en omvang van de fout en ontdekte dat in totaal 513.000 oude documenten van 212.000 patiënten permanent verloren zijn gegaan. In de brief schrijft het ziekenhuis: "Deze fout had zich niet mogen voordoen en kan zich niet meer opnieuw voordoen."

Er is melding gedaan bij de Autoriteit Persoonsgegevens, omdat er strikt genomen sprake is van een datalek. Het ziekenhuis benadrukt dat de documenten niet kwijt zijn, maar niet meer bestaan en dat ze nooit 'in verkeerde handen zijn geweest'. Ook benadrukt het ziekenhuis dat het om oude bestanden gaat, die al jaren niet meer gebruikt werden. Het ziekenhuis zegt dan ook tegen patiënten: "De kans dat er nu nog gevolgen zijn voor uw behandeling, is verwaarloosbaar klein. Alleen in bijzondere situaties waarin u in de toekomst uw volledige dossier zou willen opvragen, kunnen wij daaraan helaas niet 100 procent tegemoetkomen."

Door Stephan Vegelien

Redacteur

21-03-2022 • 14:28

179

Submitter: equit1986

Reacties (179)

179
179
85
16
0
78

Sorteer op:

Weergave:

Als je die gegevens 20 jaar moet bewaren, dan heb je toch minstens twee (cold, want het betreft enkel archivering en niet realtime beschikbare informatie) offsite backups? :?

[Reactie gewijzigd door The Zep Man op 23 juli 2024 00:19]

de "3 2 1"-regel.

3 kopie's van je bestanden.
Op 2 verschillende soorten opslag.(Bijvoorbeeld HDD/SSD's en tape)
waarvan 1 offsite.

Al zou ik bij dit soort data zelfs nog wel een stapje zwaarder gaan.

[Reactie gewijzigd door Tjidde op 23 juli 2024 00:19]

Als je een bestand overschrijft dan wordt dat ook in de backups overschreven. Bijvoorbeeld bij nachtelijke syncs. Daar gaat 3 - 2 - 1 niet tegen helpen. Je kan incrementele backups gebruiken maar die vervallen vaak ook vaak weer na een bepaalde periode om ruimte te besparen.
Alleen hoef je hier dus niet te syncen. Alle bestanden van voor 2017 hadden op een backup moeten staan waarvandaan je alleen kunt lezen, niet schrijven. Er verandert namelijk niets meer aan historische bestanden, ze moeten alleen toegankelijk blijven.
En dat mág dus simpelweg niet. De GDPR is redelijk duidelijk daarover. De "right to be forgotten" heeft géén uitzondering voor backups, maar wel andere uitzonderingen. Een rechter ziet dus dat de EU nagedacht heeft over uitzonderingen, en zal dus niet zelf dat recht verder gaan inperken.
Backup heeft helemaal niets met GDPR te maken. En backup heeft ook niets met "right to be forgotten" te maken. Backup betekent dat je bestanden terug kunt halen.
"Patiënten hebben het recht hun medisch dossier in te zien en om correctie, aanvulling, of vernietiging van hun dossier te vragen. Ook kunnen zij vragen hun gegevens over te dragen (recht op dataportabiliteit)."

Als iemand vernietiging van het medisch dossier vraagt, dan betekent dat vernietiging en niet: maar we hebben nog een oude backup dus kunnen we die gegevens gewoon weer terughalen.

Tegelijk heeft de zorgverlener een bewaarplicht van ten minste 20 jaar.

https://autoriteitpersoonsgegevens.nl/nl/onderwerpen/gezondheid/medisch-dossier
Academische ziekenhuizen moeten bepaalde documenten (het “kerndossier”) zelfs tot 115 jaar na de geboorte van de patiënt bewaren, dus daarvoor geld eventueel weer een andere termijn dan voor de rest van het dossier. Maar het is lastig dossiers zo op te splitsen, dus het maakt het weer gecompliceerder… naast de genoemde AVG en WGBO-regels… (recht op vernietiging, correctie, toevoeging etc)

[Reactie gewijzigd door begintmeta op 23 juli 2024 00:19]

Wat je dan krijgt is een plicht om bij te houden dat deze patient gevraagd heeft om de vernietiging van die data. Dat moet je sowieso bijhouden lijkt mij als je deze data anders wel moet bewaren voor een bepaalde periode. Maar dat betekend dan ook dat als je ooit een restore van een dataset doet dat de eerstvolgende actie een nieuwe opkuis moet zijn van alle verwijderverzoeken die er geweest zijn.

Wanneer je een goede backupstrategie hebt staat je long term, cold storage op read-only datadragers. En je kan redelijkerwijs niet verwachten dat men bij elk verzoek van 1 patient opnieuw gaat proberen aan te passen door deze te dupliceren en de oude te vernietigen met het potentiele risico dat je te veel data vernietigd.

Hoewel de GDPR niet in zo een uitzondering voorziet, wordt algemeen wel aangenomen dat dit een aanvaardbare oplossing is.
Als je met zo'n redenering onder het recht om vergeten te worden onderuit zou komen dan zouden alle grote databedrijven dat al lang doen. Jij als databeheerder moet zien dat je je backups op de vereiste wijze kan aanpassen zonder dat het voor jou onredelijk kostbaar wordt. Doe je dat niet, dan heb je gewoon dikke pech en moet je die kosten gewoon maken.
Toch wel. Als je zoals @Jeroenneman voorstelt dat je een soort van WORM/WriteOnly archief hebt, dan kun je het "Right to be Forgotten" (waar @MSalters aan refereert) niet uitvoeren: Immers, als ik in het WORM/WriteOnly Archief sta en eis dat mijn data wordt verwijderd, dan moet er toch geschreven/gewist worden in dat archief.
"Right to be forgotten" betekent dat je die bestanden niet kunt terughalen. Dat is een wettelijk recht, dus geen onderwerp van discussie.
Ja, met allerlei mitsen en maaren natuurlijk zoals wettelijke termijnen om data op te slaan. Het zou mooi zijn als je bijvoorbeeld een strafblad kon laten verwijderen op basis van de AVG 8)7
Voor medische dossiers bestaan allerlei regels, waardoor aanpassingen mogelijk moeten zijn (ook al eerder, zonder GDPR)
Politie heeft weer eigen regels, en die gaan een stuk verder dan avg. Bepaalde informatie mag alleen beschikbaar zijn voor bepaalde personen, die aan een bepaald onderzoek bezig zijn, en niet voor andere onderzoeken gebruikt worden. En meer van dat soort dingen.
Alleen mensen die de GDPR niet snappen zeggen dat. De GDPR stelt dat er goed over nagedacht moet worden over data opslag en dat dit niet zonder grondslag kan gebeuren.

In het geval van de opslag van gegevens rondom misdrijven is dit duidelijk vastgelegd en is de GDPR dus 'tevreden'.
Ja, maar er is letterlijk nul gerechtvaardigd openbaar belang bij het behouden van jouw persoonlijke medische gegevens. Archieven uit die je niet kan verwijderen zijn voor persoonsgegevens gewoon uit den boze tenzij je bereid bent elke keer dat je een verzoek krijgt om gegevens te verwijderen het gehele archief te vernietigen en voor de resterende bestanden opnieuw op te bouwen.
En geen enkel recht is absoluut. En elk recht is vatbaar voor discussie net omdat het niet absoluut is. Zo moet je altijd het de rechten van de ene partij afwegen tegenover de rechten en plichten van een andere partij. Het kan ook niet zijn dat door het verzoek van 1 persoon om vergeten te worden een organisatie de data van honderdduizenden andere mensen in gevaar moet gaan brengen door backups die alleen-lezen horen te zijn toch te gaan bewerken.
Ook read-only backups zijn geen perfecte oplossing. Met een beetje slimme opzet kun je nagenoeg dezelfde betrouwbaarheid bereiken zonder het recht op privacy bij cruciale persoonsgegevens te hoeven schenden.
Hoe zie je dat voor je? Stel dat de backup op een WORM medium staat, moet dit dan eerst worden uitgepakt, daarna verwijderd, en vervolgens weer opnieuw weggeschreven? Zal leuk zijn bij tablespaces, moet je eerst een hele database recovery doen?

In die paar jaar AVG/GDPR zal toch wel iemand hebben bedacht dat dit niet te doen is?
Dat de het lastig is voor iemand om uit te voeren moet natuurlijk geen argument zijn om je niet aan de wet te conformeren.

Het is ook best lastig voor mij om niet 10 kg goud mee te nemen uit de bank waar ik werk, dus moeten ze het maar toelaten?
Ja, dat heeft iedereen al lang bedacht, en de conclusie is dus dat WORM ongeschikt is om persoonsgegevens op te slaan. Wetten maken geen uitzonderingen voor onhandige keuzes jouwerzijds; dat is je eigen probleem.
Ja, dat is niet te doen. Dus moet je als beheerder jou manier van backup aanpassen ipv het recht op privacy van je patienten te schenden.
Tuurlijjk wel. Stel ik als bedrijf heb (persoonlijke) data over jou. Die stop ik in een backup.
Jij komt met het verzoek om vergeten te worden. Dan moet ik alle data over jou verwijderen, inclusief die in de backup.
Als je je backups read-only maakt gaat dat dus niet, en zul je in strijd handelen met de GDPR.
Data masking/scrubbing. Je moet alle verzoeken tot verwijdering bijhouden. Bij een backup restore voer je die verwijder procedure opnieuw uit. "Jamaar dan heb je een lijst met alle namen van personen die vergeten willen worden." Je moet de namen niet bijhouden maar alles aan een unieke sleutel hangen die op zichzelf nietsbetekenend is. Als er een nieuwe aanvraag binnen komt zoek je eenmalig die sleutel op, voeg je die toe aan de lijst en wis je daarna alle die persoon zijn gegevens uit het actieve systeem.

Wordt diezelfde persoon later opnieuw klant dan zal je niets kunnen terugvinden in het actieve systeem en wordt er een nieuwe unieke sleutel gegenereerd. De oude en nieuwe gegevens kunnen niet aan elkaar geknoopt worden. Enige manier dat dit niet GDPR compliant is als iemand aan de backups zou kunnen zonder de verwijder procedure uit te voeren en data kan uitlezen zonder dat die eerst door de scrubber/masking is gedraaid.

"Aha, dan is het nog niet veilig" Je kan het technisch onmogelijk maken om data te herstellen zonder die GDPR procedure uit te voeren. Dit vind ik zelf riskant omdat ik een systeem niet 100% meer kan terugzetten zonder dat er datamanipulatie gebeurd. Een betere oplossing is dan auditing en logging op te zetten die niet uitgezet kan worden. Zet die log op een WORM opslag en dan is dit legaal vrij sluitend. Je procedures voorzien om backups op een GDPR compliant manier op te slagen en indien overtreding is er een paper trail.

CNIL in Frankrijk gaf aan dat dit een afdoende methode is. Key zin in dit artikel: "Backups should only be used for restoring a technical environment, and data subject personal data should not be processed again after restore (and deleted again)"
In dit geval gaat het niet alleen om vergeten willen worden, maar ook om correcties of gedeeltelijke verwijderingen of toevoegingen (je moet dus wel iets terugvinden, maar niet alles, of iets anders dan het was/vanwege o.a de WGBO (en het zijn als bijzonder gevoelig geclassificeerde gegevens)). Op zich natuurlijk op dezelfde manier te verwerken lijkt me, maar ik ben benieuwd naar je inschatting van hoeveel complexer zo’n systeem daarvan wordt.

[Reactie gewijzigd door begintmeta op 23 juli 2024 00:19]

De meeste features die je nodig hebt zijn al voorzien in allerhande databases, backupsoftware en security/auditing tools. Als er bij nieuwe ontwikkelingen aan GDPR gedacht wordt kan in een applicatie alles aan bijvoorbeeld GUID's gehangen worden.

De miserie begint bij bestaande applicaties en het spinnenweb dat zich in meeste bedrijven opbouwt. Als je dan opeens afkomt dat alles GDPR compliant moet worden. fuggedaboutit...
Ik zou hier wel eens rechtspraak over willen zien. Volgens mijn info is het niet zo zwart/wit.

Er is nog zoiets als proportionaliteit.
Een heel goed punt.

Als je aantoonbaar heel erg je best hebt gedaan om het zo goed mogelijk te doen is het de vraag hoe heet de soep gegeten wordt. Zeker als je duidelijk kan maken dat nog meer doen risico's voor de gegevens van anderen betekent. Die discussie kan je wel aan gaan.
Medische dossiers hebben een wettelijke bewaarplicht die boven de gdpr gaat. Om de patiënt te beschermen....
En het ziekenhuis, voor het geval er een probleem pas na jaren aan het licht komt en het ziekenhuis moet bewijzen juist gehandeld te hebben. Dat gaat natuurlijk niet als de patient eerst de data laat verwijderen en een half jaar later met een juridisch team voor de deur staat en jij als ziekenhuis geen bewijs meer hebt omdat je dat moest wissen van de patient.

Daarom gaat die bewaarplicht boven de gdpr.

In dit geval zou er toch nog wel een jaarbackup zijn van 2020 die eind december gedraaid is? Dan moet een groot deel van die data daar toch nog wel uit te halen zijn.

[Reactie gewijzigd door SunnieNL op 23 juli 2024 00:19]

Een patiënt kan geen data laten verwijderen. Hij kan wel een verzoek doen zijn dossier te laten vernietigen maar kan daarna natuurlijk niet komen klagen. In principe ligt de bewijslast bij de klager, die moet aannemelijk maken dat er iets niet goed is gegaan. Meestal zal dan het dossier opgevraagd worden maar als daarin data ontbreken zal een tuchtcollege daardoor niet eerder tot een gegrond verklaring komen.

Ik sla bijvoorbeeld altijd foto's op van mijn behandelingen maar je kan er ook prima voor kiezen dat juist niet te doen omdat de patiënt ermee zou kunnen aantonen dat er iets niet goed gegaan is. Het tuchtcollege kan daar wat van vinden maar je niet straffen als het bewijs domweg ontbreekt.

Wat ik begrijp is dat het passieve secundaire data betreft. Dus oude verwijsbrieven en dergelijke waarvan eigenlijk al bedacht was dat die niet meer nodig waren. Ik begrijp dan ook eigenlijk niet goed waarom die in een actief systeem zitten.
Voor de GDPR kun je natuurlijk een uitzondering maken waarbij je alleen de personeelsleden verantwoordelijk voor GDPR taken bepaalde rechten toekent.

Maar een archief direct koppelen aan het EPD, en hierop ook schrijfrechten verlenen klinkt als een bizarre constructie.
Het is inderdaad zo dat je kunt optimalizeren - de overgrote meerderheid van backup writes zijn geen GDPR "right to be forgotten" updates.
Je mag de documenten nog steeds in de backup hebben staan. Je moet alleen een correct process hebben om die documenten in geval van een restore weer te verwijderen uit de online versie. Zo gaan wij er tenminste mee om.
In basis heb je gelijk, los van de AVG discussie die wat nuances aanbrengt.

Het probleem is dat ze aangemerkte historische bestanden konden overschrijven, los van je backup strategie zou er in je monitoring een belletje af moeten gaan als een proces bestanden aan het overschrijven is in structuren waar dat niet mag.

Ik ben benieuwd waar de verantwoordelijkheid hier ligt bij de EPD leverancier of het ICT beheer.

[off topic] Voelt een beetje als die xerox machine die bij scans getallen op bouwtekeningen verkeerd las en aanpaste. https://www.bbc.com/news/technology-23588202

edit: typo

[Reactie gewijzigd door BrennuS op 23 juli 2024 00:19]

Ik zou mijn tapes nooit overschrijven bij dit soort data. Vol = vol. Zeker als je een bewaarplicht hebt van 20 jaar.
Het zijn tapes van het ziekenhuis. Tenzij jij in je eentje de beleidsmaker van het ziekenhuis bent, denk ik dat jij daar niets over te zeggen hebt.
Sterker nog: wanneer het beleid zegt dat een medium vernietigd moet worden, dan is het tegen de regels in bewaren van een tape reden voor ontslag.
Als je een bestand overschrijft dan wordt dat ook in de backups overschreven.
Huh? Als dat zo is wat is dan de reden om te backuppen?

Enige reden voor backup bij ons is om bestanden terug te kunnen halen die om een of andere reden kwijt of beschadigd zijn.
Dat ligt inderdaad aan de insteek van je backups en de daarvoor gebruikte methode.

Raid 1 zou je als een backup kunnen zien, is ook wel waar, tot een zekere hoogte. Maar komt er ransomware voorbij, dan is je backup ook de lul. Dit soort backups is dan ook meer tegen hardware falen (als 1 van de 2 schijven stuk gaat, kan je verder met de ander) en dus niet tegen foutieve data mutaties.

Een andere reden om te backuppen is tegen corruptie / bugs (of andere software gerelateerde problemen) / menselijke fouten en dat doe je dus periodiek ipv realtime.
Ik snap dat dus niet, ik maak elke dag een backup van mijn home folder van mijn pc naar twee harde schijven lokaal raid 1, en daarnaast 1x per dag naar de cloud, versleuteld uiteraard. Dit gaat gewoon incrementeel, dus als op een dag malware mijn home folder encrypt, dan kan ik gewoon een versie terugzetten van voor de malware. Als mijn huis afbrandt, kan ik later van de cloud terugzetten, als een dief mijn computer meeneemt idem dito, en daarbij zijn alle schijven versleuteld dus kunnen ze ook niks mee. Raid 1 is gewoon geen backup, is alleen maar handig om snel de boel terug te kunnen zetten als dat nodig is.
En als 2 jaar geleden een selectie van bestanden overschreven zijn en je ontdekt dat pas vandaag. Kun je die dan nog terug vinden in je backup?
De kans is groot dat de files niet los in een filesystem staan, maar dat er ook databaseverwijzingen in het EPD staan. De bestandsnaam is een ongelukkig gekozen primary key. Nu is de primary key niet uniek meer en moet je dus niet alleen de bestanden restoren, maar ook de databaseverwijzingen weer op correcte wijze bij elkaar puzzelen.
Dat kan natuurlijk gewoon, maar inclusief verificatie met 0 foutmarge is dat een kostbare zaak. De kans is groot dat het als niet-reëel bestempeld is omdat de kosten niet tegen de baten opwegen.
Niet helemaal mee eens. Oude backups worden niet overschreven als je een data retentie hebt van 20 jaar wat hier het geval had moeten zijn.
Lastige is dus dat oude backups wel moeten worden vernietigd zoals al meer hier geschreven wordt: als ook maar één iemand gebruik maakt van zij/haar recht om vergeten te willen worden moeten alle backups waar dat dossier op staat vernietigd worden, regel van de GDPR/AVG. Dus elk weldenkend bedrijf heeft inmiddels ingericht dat een backup systeem iets anders werkt dan voorheen waar je inderdaad je week, maand en jaartapes bewaarde etc.
Dat klopt niet. Je hoeft geen persoonsgegevens uit backups te halen. Je moet wel een procedure hebben om bij een restore te voorkomen dat die persoonsgegevens weer in productie terecht komen. Dat heet 'staged restore'

De meeste persoonsgegevens zijn voorzien van een uniek ID. Als iemand zijn gegevens laat verwijderen dan wordt alles weggegooid behalve dat unieke ID. Bij een staged restore wordt de data in een tijdelijke locatie teruggezet, waarna de lijst met verwijderde ID's gebruikt wordt om de persoonsgegevens weer te wissen. Daarna kan de restore door naar productie.
Tsja er zijn allemaal manieren om dit te regelen enige punt wat ik maakte was dat er geen backups veevallen etc.

Maar goed hier laten we het maar bij.
3 kopieen, 1 offsite? Dan moet je wel heel ongelukkig backup-en en blunder-syncen als je dat principe wil verpesten
Dan ben je niet voorzichtig genoeg met je data en is hier echt wel sprake van nalatigheid.
Dat zou wel heel bijzonder zijn. Als je de backup van 6 jaar geleden terughaalt, dan zullen alle bestanden inclusief hun oorspronkelijke namen terugkomen. Je kan ze alleen niet terugzetten naar waar ze vandaan kwamen, want daar staan nu andere bestanden met dezelfde naam. Dus zal je ze moeten restoren naar een alternatieve locatie.Heel kort door de bocht:
C:\mijnmedischbestand1234.txt is het huidige bestand uit 2022
D:\mijnmedischbestand1234.txt is het teruggehaalde bestand uit 2016.

Nu nog je applicatie vertellen dat er naar D: gekeken moet worden in plaats van C:, al is het maar om in te kunnen zien.
Zoals maand en jaar backups ...
Maand- en jaar tapes was een aardig concept voor de dataexplosie.
Maar tegenwoordig geldt ook in de medische wereld "pics or it didn't happen" of liever nog ... een high resolution filmpje. Dat betekent dan een EPD makkelijk een paar honderd petaByte kan zijn. Bedenk even hoe je daar iedere maand een kopietje van trekt.
Alles kan natuurlijk, maar bedenk dat ook een ziekenhuis zijn euro maar 1x uit kan geven. Alle euro's die in die kopietjes gaan zitten, gaan ten koste van handen aan het bed en ten koste van medicijnen (Ziekenhuizen krijgen niet alles vergoed wat ze experimenteel toedienen)
Een paar ton aan backup faciliteiten kost dus ook gewoon een paar levens..
Daar gaat 3 - 2 - 1 niet tegen helpen
Hij geeft aan dat een van die back-up Tapes zijn. Tapes is je Cold storage, daar gaat een daily/weeky/monthy overheen en daarna uit de tapedrive. Dan gaat er een nieuwe tape in. Deze tapes bewaar je dan ergens veilig, bijvoorbeeld in een kluis. Dit kan bij een 3e partij zijn die ze voor je bewaard.
Deze tapes zijn dus fysiek ergens anders, en niet in een tapedrive en kunnen dus niet overschreven worden. Sterker nog, je kan de tapes een hardwarematige write-protection geven.Op de LTO's van HP is dit een Roodschuifje en kan de tapes niet meer overschreven worden.

Dus, als de Offsite back-up je Tapes zijn dan werkt de 3-2-1 wel degelijk. Tapes hebben vaak ook een enorm goede encryptie er overheen en is daarom een goede keuze als offsite-cold backup. Het is maar net hoe je de 3-2-1 regel implementeert.
de "3 2 1"-regel.
(...)
Al zou ik bij dit soort data zelfs nog wel een stapje zwaarder gaan.
Namelijk?
Simpel. Da's de "4 3 2 1"-regel.

4 kopieen van je bestanden
Op 3 verschillende soorten opslag
Waarvan 2 off site
En 1 heel goed verstopt

Of zoiets :-)
Goed verstopt hoeft niet denk ik.

Maar wel bijvoorbeeld 1 in de cloud(al helpt cloud niet met overschrijven)
2x op tape een in een kluis in je eigen gebouw voor als je het snel nodig hebt. En in een kluis extern mocht je last hebben van brand heb je je oudere tapes nog.

Jammer is wel de back-uppen altijd een ondergeschoven kindje is. Aangezien mensen die er geen verstand van hebben pas de waarde ervan inzien als het te laat is. Want het levert toch geen geld op.

Dat gezegd heb ik het wel te doen met de sys-admin die hierachter kwam. Dataloss lijkt mij het ergste wat er is als je in die functie zit.
Want het levert toch geen geld op.
Ik heb anders al vele malen geld bespaard dankzij mijn backups.

HDD gaf plots de geest -> Nieuwe HDD erin, bestanden terugzetten en gaan met die banaan.
Per ongeluk een bestand overschreven? Cloudbackup downloaden en ik kon weer verder.
...
Een defecte HDD wordt in je storage unit toch automatisch vervangen voor een van de hot spares?
Data die op straat beland lijkt mij echt 1000x erger.
Oude hardware die het pand verlaat zonder dat de datadragers eruit verwijderd zijn.
Laatst is in Breda een verwerker (vernietiger) van storagemediums uitgebrand.
Dan heb je alles goed gedaan en nog ligt die Raid1-schijf met die database opeens binnen bereik van onbevoegden.
Nou namelijk er kunnen zaken lopen ( ja meerdere jaren zelfs ) waarbij bijvoorbeeld letselschade moet worden verhaalt op een tegen partij of zelfs het ziekenhuis door nalatigheid of dergelijk , dan is het zowel cruciaal voor een ziekenhuis zelf en of om een partij documenten voor te leggen omtrent behandeling bijvoorbeeld.

Dus 86ul heeft een goed en zelfs sterk punt dat je nog een stapje zwaarder zou kunnen gaan.
Het gaat niet om alle gegevens van 5 jaar en ouder. Enkel gegevens waarvan de arts dacht dat ze niet langer van belang waren. Bij lopende zaken werden de gegevens aan het EPD toegevoegd.
Een extra lange-termijn kopie off-site zou niet heel gek zijn, maar de exacte implementatie is niet heel belangrijk. Tjidde bedoelt denk ik gewoon dat bij normale bedrijven de "3 2 1" regel al aangeraden wordt. Bij ziekenhuizen is de informatie nog wel een stuk belangrijker en wordt de informatie vaak ook voor langere termijn opgeslagen. Over langere termijn is er meer kans op problemen en wordt het ook rendabeler om de informatie op tape te zetten.
Bij medische data overschrijf je nooit een bestand, maar voeg je een nieuwe versie toe in de repository.

Als Commissioning Engineer en Consultant ben ik betrokken bij de fabricage van complexe machines, dat zijn soms unieke exemplaren (offshore hijskraan, pijplegtoren etc.) en soms ook serie producten die gedurende langere tijd gebouwd worden (trams, passagierstreinen, locomotieven).
Bij de unieke exemplaren is het makkelijker, want er is gewoon een unieke tekeningen pakket.
Problemen kunnen ontstaan bij de serie producten, ik kan je garanderen dat door voortschrijdend inzicht er best veel kan veranderen in de loop van jaren. Dus als je voor een modificatie of andere service aan tram type A uit jaar 2012 je dus niet het tekeningen pakket van tram type A uit 2021 moet meenemen, want dan heb je een probleem op locatie omdat bijvoorbeeld het elektronische pakket compleet gewijzigd is, er een nieuwer type elektromotoren met hogere efficiëntie gebruikt zijn, en de deuren niet pneumatisch maar elektromechanisch zijn. Dat alles zonder dat je aan de buiten of binnenkant (afgezien van de bouwplaat met serienummer en bouwjaar) kan zien welke ontwerp-iteratie het betreft.

De ontwerp engineer maakt dus wel een nieuwe tekening met de wijziging, maar de oude tekening (met dezelfde bestandsnaam) wordt nooit overschreven. Trams zijn wat dat betreft een goed voorbeeld, want deze zijn ongeacht aan wie ze geleverd worden (indeling van het passagiers compartiment is de uitzondering, maar voor de technische kant niet heel relevant) zo goed als identiek.
De veiligheids systemen zijn overigens altijd een losstaand pakket, de interface van de tram zelf is voor alle versies identiek, en redelijk flexibel te configureren. Zo ongeveer alle railbeveiligingssystemen werken volgens het principe "commanded, received, acting".
Je hebt ook opslagsystemen waarbij meteen de eerste inititiele schrijfactie niet meer aangepast kan worden. Dus write-once, niet alleen voor de backups die volgen, maar gewoon zodra een bestand is weggeschreven kun je het niet meer overschrijven of verwijderen.
zgn WORM systeem en dat mag dus niet meer van AVG, want als ik gebruik wil maken van het recht om vergeten te worden moeten alle kopieën van mijn dossier worden vernietigd. Als die op een medium staan wat niet meer overschreven of gewijzigd kan worden dan rest de organisatie niets anders dan het hele medium te vernietigen. Daarmee is die backup methode dus niet meer bruikbaar voor een organisatie die zich aan de AVG houdt.
Dat kan door alle bestanden te versleutelen met een unieke sleutel per dossier/patient. Komt er iemand die zijn dossier vernietigd wil hebben, gooi je de sleutel weg. Fysiek hoef je de backups dan niet te vernietigen, als dat onmogelijk is.
Over 10 jaar quantumcomputers op de markt die die sleutel in luttele seconden kan genereren/bruteforcen en dan liggen je "verwijderde" gegevens alsnog op straat?
Als de tijd ons iets geleerd heeft is het wel dat wat we nu veilig of onkraakbaar achtten over 10 jaar zo lek als een mandje blijkt...
Beste Laurens,
Uw uitspraak is helaas niet geheel correct. De AP vermeld duidelijk:
Is het noodzakelijk voor uw dienstverlening om back-ups te maken die moeilijk of niet overschrijfbaar zijn, zoals tapes? Dan kunt u de persoonsgegevens niet verwijderen uit de back-ups. Zorg dan wel dat u goed bijhoudt welke persoonsgegevens u had moeten verwijderen. Is het onverhoopt nodig om een back-up terug te zetten? Dan moet u deze gegevens alsnog verwijderen.
Bron:https://autoriteitpersoon...g/rechten-van-betrokkenen

Het is dus belangrijk om door de Functionaris Gegevensbescherming een register bij te laten houden met alle wis en wijzigingsverzoeken. Deze gegevens zijn uit privacyoogpunt natuurlijk voor de rest van de organisatie niet beschikbaar. Wanneer een (tape) restore nodig is, moet geverifieerd worden dat de gegevens van de betrokkene na de restore weer verwijderd zijn of worden of weer gecorrigeerd.
1 offsite, bedoel je dan bij een third party ? want dat mag niet zomaar he.
Het kan een pand zijn van jezelf of gehuurd(maakt niet veel uit). Koop/huur een pand aan de andere kant van de stad zet dat een paar servers in voor je storage. En je hebt offsite storage.

Al zou ik in een geval van een ziekenhuis er twee hebben. 1 serverrek en 1 kluis met tapes.
Bij de meeste instanties is het 1, 2, 3 foetsie.
Wat ouderwets. Dit mitigeert de oorzaak van het probleem niet. De data loss die ik met name tegen kom is de perceptie van mensen dat opslag veel geld kost. En overijverige mensen die denken dat als een centrale organisatie niet weet van die de data is, dat het dan weg moet.

Bovendien waarom niet gewoon op cloud blob storage, indien goed ingericht heb je meer durability dan met je 1-2-3 oplossing bij elkaar. Incl. Crypolock preventie. Met een bandbreedte waarvan je met je huidige backup oplossingen alleen maar kunt dromen.

Ik heb er zelfs een DOS mitigatie mee ontworpen die business continuïteit garandeert zelfs tijdens attacks als core systemen uit de lucht worden geblazen. Tegen kosten die nagenoeg gelijk zijn aan de kosten die de aanvaller maakt.

[Reactie gewijzigd door djwice op 23 juli 2024 00:19]

Dan moeten ze ziekenhuispersoneel flink meer gaan betalen, want in genoeg organisaties hangt de ICT aan een zijden draadje. Verzuim onder personeel is hoog, salaris is in relatie tot ICT buiten de zorg laag, ziekenhuizen zitten op een nul-lijn qua inkomsten en investeringen worden met moeite gedaan.

Waarschijnlijk is het wel te vervangen, maar dat vereist specialistische kennis, en dat is duur. Ze hopen hier met een tik op de vingers weg te komen.

Overigens ook bizar dat men akkoord is gegaan met de vernietiging van de papieren versies. Er zijn nog talloze ziekenhuizen die bunkers huren om daarin alle oude documenten te bewaren, omdat alles inscannen geen doen is, maar omdat ze ook moeten blijven voldoen aan de bewaringsplicht.

Ook onduidelijk of er nu wel of geen koppeling aanwezig is tussen het archief en het EPD.

Bij de invoering van het EPD werden de oude papieren documenten gescand en opgeslagen in een digitaal archief. Het ging hierbij om bestanden waarvan de arts dacht dat ze nooit meer nodig zouden zijn en die daarom niet toegevoegd werden aan het EPD. De papieren documenten werden destijds vernietigd. Het gaat om bestanden van voor september 2017.

Bestandsnamen overschreven
Sinds 2017 worden nieuwe, actuele documenten digitaal toegevoegd aan het EPD, legt het ziekenhuis uit. Daarbij is een fout gemaakt, waardoor tussen november 2020 en oktober 2021 de oude, gearchiveerde bestanden werden overschreven door nieuwe bestanden die door artsen werden toegevoegd. De fout kwam aan het licht toen een behandelaar de historische gegevens van een patiënt wilde inzien, maar een nieuwer document tegenkwam. Dit bleek in de plaats gekomen te zijn van de oude scan.

Hoe kan dit? De oude bestanden die niet gekoppeld waren aan het EPD staan toch hopelijk op een aparte archief locatie? Hoe kunnen er nieuwe bestanden die in het EPD worden aangemaakt dan de oude bestanden overschrijven? Die stonden toch juist in een apart archief, niet gekoppeld aan het EPD?
Simpel, de EPD wist dus niet van deze oude bestanden af en de naamgeving er van. Die oude bestanden waren dus via een andere weg nog te benaderen (map op patientnummer). De EPD slaat ook bestanden op in diezelfde map op patientnummer (je wilt immers niet meerdere locatie met patientdata moeten doorlopen). Echter, doordat de EPD niet wist van bestaande bestanden heeft deze gewoon de oude bestanden overschreven.

(zomaar een manier waarop dit had kunnen gebeuren. Ik werk er niet en werk ook niet met chipsoft, dus het is gok werk. Maar er zijn wel wat manieren te bedenken hoe dit kan gebeuren)

[Reactie gewijzigd door SunnieNL op 23 juli 2024 00:19]

Ik werk in een ziekenhuis op de IT afdeling. Helaas zou je van bepaalde zaken verwachten dat het goed op orde is, maar veel (en dan bedoel ik echt heel veel) zit met een spreekwoordelijk pleistertje op z'n plaats.
De wil om te optimaliseren leeft niet buiten de IT afdeling, dus kabbel je maar een beetje voort...

Het verbaast mij dat dit soort problemen niet vaker voorkomt.
Wees gerust, dat is echt bijna overal zo. Niet enkel bij jou.
Ik werk in een ziekenhuis op de IT afdeling, (veel) zit met een spreekwoordelijk pleistertje op z'n plaats.
Ziekenhuizen hebben tenminste nog ervaring met pleisters. Voldoende plaatsen in 'het bedrijfsleven' waar het ook zo gaat, terwijl die niets met pleisters te maken hebben en wel budget hebben.
De wil zal er ongetwijfeld zijn. De middelen om het uit te voeren zullen ontbreken.
Als je die gegevens 20 jaar moet bewaren, dan heb je toch minstens twee (cold, want het betreft enkel archivering en niet realtime beschikbare informatie) offsite backups? :?
Uit het artikel,
Het ging hierbij om bestanden waarvan de arts dacht dat ze nooit meer nodig zouden zijn (...)
tussen november 2020 en oktober 2021 de oude, gearchiveerde bestanden werden overschreven
Ook met de door @Tjidde aangehaald 3-2-1-backups: doorgaans heb je een paar recente sets, een paar van een paar maanden oud en misschien tot een jaar terug.

November 2020 is zowat anderhalf jaar geleden. De bestandsnamen zijn er nog wel degelijk, met het backupbeleid is dus niets mis.

Met wat voor naamgevingsconventie je met een bestand uit 2020 een bestand van 2016 kunt overschijven vraag ik me wel af, maar misschien is een datumcomponent ongebruikelijk in de medische wereld.
...
Met wat voor naamgevingsconventie je met een bestand uit 2020 een bestand van 2016 kunt overschijven vraag ik me wel af, maar misschien is een datumcomponent ongebruikelijk in de medische wereld...
Gewoon overnieuw begonnen met tellen, waarschijnlijk 00000001.pdf, 00000002.pdf, 00000003.pdf etc
Uit het artikel,

[...]
Uit het artikel:
De documenten hadden twintig jaar bewaard moeten blijven,
Artsen gaan niet over hoe lang data bewaard moet blijven. Dat doen beleidsmakers, gebaseerd op veel verschillende bronnen (medische experts, wetgeving, ...). De uitvoer wordt gedaan door IT'ers.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 00:19]

Het klinkt alsof hun EPD software "vergeten" is om een check in te bouwen of een bestand al bestaat.
Wat mij betreft ligt daar de eerste fout, nog voordat we over backups beginnen.
Het klinkt alsof hun EPD software "vergeten" is om een check in te bouwen of een bestand al bestaat.
Wat mij betreft ligt daar de eerste fout, nog voordat we over backups beginnen.
Het is een vaag verhaal, maar het gaat inderdaad al ruim voor de backups niet goed. Dat van de half miljoen bestanden er pas na 5 jaar eentje opgevraagd wordt, maakt het niet goed, maar laat ook wel een beetje zien waar de kosten voor gemaakt hadden moeten worden.
Inderdaad een raar verhaal dit. En dat het niemand ooit eerder is opgevallen gaat er bij mij ook niet in.
Indien dit verhaal correct is. Dan zit of zat er een knots van een bug in de software. En zullen andere ziekenhuizen naar alle waarschijnlijkheid met het zelfde probleem te maken hebben gehad.
De software had moeten melden dat er een bestand overschreven zou worden. Of beter nog, het niet toe staan dat er data overschreven word.
DMS'en zijn complexe dingen. Dit kan net zo goed door verkeerde configuratie ontstaan.
Mogelijk is er data overschreven door wijzigingen buiten de software om, b.v. op database niveau. Dat zoiets is gebeurd is slordig, maar vind ik nog ergens verklaarbaar. Het feit dat er geen goede back-ups zijn terwijl gegevens 20 jaar bewaard moeten worden baart mij meer zorgen. Dit soort fouten kunnen levens kosten.

[Reactie gewijzigd door Sjaakys op 23 juli 2024 00:19]

Een grote bug is mogelijk, maar het kan ook zijn dat de software deed wat moest en dat niemand de developer heeft verteld dat er nog oude data in de weg kon zitten. Makkelijk om de ontwikkelaars de schuld te geven. Maar ik weet uit eigen ervaring dat je vaak genoeg gewoon dat soort informatie niet krijgt. Alleen een specificatie van wat je moet bouwen. En daar kan prima overschrijving in worden toegestaan of verplicht. Of je het daar nu mee eens bent of niet.
Een knots van een bug is één ding, gebrek aan een goed back-upsysteem is een heel ander verhaal. Als dataretentie zo ontzettend belangrijk is, dan stel je toch een heel back-upplan op dat zo redelijk mogelijk waterdicht is? Zo'n bug is te fixen en mbv back-ups zou data, indien nodig, hersteld kunnen worden maar dat laatste kan nu dus niet meer.
Het heeft te maken met de overgang van papier naar digitaal staat in het artikel. Dan moet je een soort uitgangsituatie zien te creëren waar je van de een op de andere dag verder kan werken in een digitaal dossier. Dat is geen situatie die zich elke dag voordoet in ziekenhuizen.
Onbegrijpelijke fout. Wie gaat er nou backupbestanden overschrijven? Betekent dat ze bij een ransomware aanval ook al hun bestanden kwijt zijn, inclusief backup?
Onbegrijpelijke fout. Wie gaat er nou backupbestanden overschrijven?
Wie krijgt er bij 0-budget wel budget voor een extra backup-array, terwijl dezelfde data ook al tweemaal ergens anders opgeslagen is?
Betekent dat ze bij een ransomware aanval ook al hun bestanden kwijt zijn, inclusief backup?
Nee, natuurlijk niet, zo'n ransomwareboer gaat niet twee jaar wachten om te vragen om z'n losgeld.
Er staat niet dat de backups overschreven zijn, er staat dat de originele bestanden overschreven zijn. Daarvan worden weer nieuwe backups gemaakt en volgens een expiratie criterium zullen de oude backups (met de oude data dus) na verloop verdwijnen.
Spijker op z'n kop!
wellicht dat ze daar ook een overijverige vruchtbaarheidsarts hadden en nu collateral damage willen voorkomen :+
Tja, en dan komt er een IT-compliance officer langs die zegt dat alles wat geen "tag" heeft - die compliance net vastgesteld heeft - moet worden verwijderd. Netjes een dag vooraf waarschuwing naar het emailadres dat in een tag moet staan die 2 jaar geleden is ingevoerd, voor het geval dat.
En heeft voor alles wat minder dan 100k eenmalig kost een vrijbrief van de directie. Uitgaande van goede staat van dienst en goede intenties.
Oude bestanden hadden die tag nog niet. Jonge IT-er implementeert de regel voort varend op donderdag en oeps, die zaterdag zijn heel veel oude bestanden verdwenen.

Er zijn IT-ers die "gewoon" admin rechten tot alle data toekennen als ze denken dat compliance of security wil dat hun script een bepaalde actie moet doen. Review in zelfde team met zelfde inde vlek, aansturing door mensen die alleen vragen of de vraag van compliance/security al is uitgevoerd.

Tegenwoordig kun je op AWS S3 ook definiëren dat een bestand niet mag worden gewijzigd én dat de policy doe dat bepaalt zelfs met de hoogste admin rechten niet kan worden verwijderd.
Je weet nu waarom zo iets bestaat.

[Reactie gewijzigd door djwice op 23 juli 2024 00:19]

Of gewoon HIPAA compliant. Natuurlijk zijn cold / archief functies belangrijk maar meer de retentie (onverwijderbaar) en immutability (onaantastbaar) is in dit scenario belangrijker denk ik.
Goed om te weten dat alleen bestanden in dossiers verwijdert zijn. Het dossier van een patient bestaat nog wel. Dus het feit dat iemand een botbreuk heeft gehad 5 jaar terug staat gewoon nog in het systeem. Het kan alleen zijn dat de foto’s hiervan weg zijn.
Die van mijn vader heb ik eens opgevraagd, daar vertelde men mij dat de bewaarplicht wettelijk is vastgelegd op 15 jaar, deze bestonden ook niet meer en alleen zijn naam was nog zichtbaar.
staat inderdaad wettelijk vastgelegd:
https://www.rijksoverheid...r/bewaren-medisch-dossier

al zijn deze wel bijzonder:
Andere wettelijke bewaartermijn
Academische ziekenhuizen moeten bepaalde documenten bewaren tot 115 jaar na de geboortedatum van de patiënt, zoals het operatieverslag en de ontslagbrief. Dat komt omdat op deze gegevens de Archiefwet van toepassing is.

Bij gedwongen opname: bewaartermijn 5 jaar
Medische gegevens van psychiatrische patiënten die gedwongen zijn opgenomen moeten minimaal tot 5 jaar na hun ontslag bewaard blijven. Deze bewaartermijn komt voort uit het Besluit Patiëntendossier Bopz.
"Oude bestanden, die al jaren niet meer worden gebruikt"

Het betreft bestanden van voor 2017: lijkt me toch dat er behoorlijk wat recente jaargangen bij zijn. Hoe kunnen die al jaren niet meer gebruikt zijn.
Oude labuitslagen heb je niet meer nodig als er nieuwere zijn. Zo ook met scans.
Is een kanker verwijderd, dan hoeft de informatie over een biopt niet meer benaderd te worden. Eventueel neem je een nieuw biopt bij recessie.
Ziektes kunnen genezen zijn. Patienten kunnen inmiddels overleden zijn. Kinderen (waarvoor vruchtbaarheidsbehandelingen gestart waren) kunnen geboren zijn.

Wij hebben in onze kliniek bakken data (digitaal en op papier) die we op slaan omdat we het op moeten slaan maar waarvan ik met 99,9% zekerheid kan zeggen dat we ze nooit nodig gaan hebben.
Daar zit voor een groot gedeelte ook data bij die patient overstijgend is, maar toch.
Het bewaren van medische gegevens voor 20 jaar heeft wel degelijk een praktische oorsprong. Er zijn genoeg biologische en medische processen die over meer jaren lopen. Kijk bijvoorbeeld naar het groeien van kinderen. Het kan soms nodig zijn om de gegevens van jaren geleden terug te zien.

En ja, dan wil je de rauwe gegevens terug zien, niet de interpretatie van toen, met de medische inzichten van toen. Maar juist de relatie met nu.
Sinds 2017 worden nieuwe, actuele documenten digitaal toegevoegd aan het EPD, legt het ziekenhuis uit. Daarbij is een fout gemaakt, waardoor tussen november 2020 en oktober 2021 de oude, gearchiveerde bestanden werden overschreven door nieuwe bestanden die door artsen werden toegevoegd.
Zoals ik het lees is alleen bepaalde data overschreven, niet alles. Maar wellicht lees ik het verkeerd :)
Klopt niet helemaal
Transfusie informatie is zelfs na 5 jaar nog informatief.
Scheelt ook weer een bloedafname als ze ooit al eens je bloedgroep bepaald hebben.
Eerdere info mbt tumormarkers kunnen ook informatief zijn.

Maar kan best zijn dat die info er nog allemaal is aangezien het LIS een apart onderdeel is binnen Chipsoft of vaak via een andere leverancier loopt. Zelfde geldt vaak voor de rontgen wat in een PACS staat
In de brief staat dat het gaat om 513.000 oude documenten permanent verdwenen van in totaal circa 212.000 patiënten, en dat artsen al hadden beoordeeld welke bewaard moesten blijven. 2.5 documenten per patient lijkt me al behoorlijk gefiltered.

Van mijn eigen (toegegeven, lange) elleboog traject heb ik zelf al meer dan 30 documenten vanuit het ziekenhuis gekregen, dus wie weet hoeveel dingen ze van me hebben opgeslagen, meer dan 2.5 in ieder geval..
Is een kanker verwijderd, dan hoeft de informatie over een biopt niet meer benaderd te worden. Eventueel neem je een nieuw biopt bij recessie.
Dit is inhoudelijk een extreem slecht voorbeeld. De richtlijnen in de pathologie (het lab dat een biopt analyseert) gaat heel bewust uit van een bewaartermijn van minimaal 20 jaar, en daarna zolang medisch relevant. Juist bij kanker is er de kans op het later ontdekken van metastases, en dan is juist gedetailleerde kennis van de originele tumor van belang om de juiste diagnose te kunnen stellen. En langzame metastases duren jaren soms decennia voordat ze ondekt worden. Dus die voorgeschiedenis is juist van belang, zeker omdat je niet een tweede biopt kan nemen om het werk nog eens over te doen.
En dan blijkt dat ene merk van dat stofje wat je gebruikte bij de vruchtbaarheidsbehandeling een vervuiling te hebben gehad waardoor kinderen na 20 jaar een afwijking ontwikkelen...

Dat weet je nu niet, kun je ook niet voorzien op dit moment. Maar dat vind je op het moment dat het over 20 jaar plaatsheeft toch ineens bijzonder belangrijk omdat je als de ontwikkeling van de afwijking een bepaalde grens nog niet gepasseerd is, je de patiënt nog kan redden ipv dat die plotseling dood neervalt. Extreem voorbeeld, maar er zijn gevallen bekend (o.a. Softenon)
Het zou wat zijn als dat gebeurde: data vernietigen nadat kanker eruit is, iemand genezen of overleden is.

Weg alle onderzoeksgegevens en relevante data. Weg revisie materiaal etc etc. Weg vooruitgang in de medische wetenschap.

Niet voor niets eerder 15 en nu 20 jaar bewaarplicht.
Als op een gegeven moment blijkt dat bepaalde materialen voor implantaten, kunstgewrichten etc. giftig zijn, dan zou ik wel willen kunnen laten opzoeken welk materiaal ze bij mij in het verleden hebben gebruikt.
dan hoeft de informatie over een biopt niet meer benaderd te worden.
Oh nee? Na wat voorvallen in de familie werd besloten een biopt van een iemand na jaren opnieuw te onderzoeken om na te gaan of het probleem in de familie genetisch bepaald was. Dan heb je de oude toch echt nodig.
Bovendien: als de regel is "20 jaar bewaren", dan is het niet aan een persoon om dat te overrulen.

[Reactie gewijzigd door CPV op 23 juli 2024 00:19]

Lijkt me logisch het is meer dan 5 jaar geleden. Als ik 5 jaar geleden mijn enkel heb gebroken en dat is hersteld en in die tijd heb ik niks meer met mijn enkel gehad. Heeft niemand ooit in die bestanden hoeven te kijken. Het gaat namelijk over bestanden in de patiëntendossiers niet over de dossiers zelf
En dan ontstaat er iets op de plek waar jij ooit je enkel hebt gebroken. Dan is het misschien toch wenselijk dat de arts nu kan zien waar en hoe vroeger de schroeven door je enkel heen gezeten hebben, ook al zijn die er al lang uit vandaan.
Ik zeg niet dat ze niet relevant zijn, ik leg uit hoe het kan gebeuren dat er 5 jaar niet naar gekeken wordt.
Natuurlijk is het belangrijk dat ze bewaard blijven vandaar de regel van 20 jaar. Alleen kan het redelijk makkelijk voorkomen dat er meerdere jaren niet naar gekeken hoeft te worden. Daar ging de reactie over waarop ik reageer.
Tenzij er allerlei ziektes bij je familie voorkomt. Dan kan het zo zijn dat je deze oude gegevens nodig hebt.
Dan worden de documenten niet gearchiveerd, maar blijven ze in het EDP zitten.
Kijk naar wat er met lekkende siliconen is gebeurd. Informatie over de gebruikte materialen en foto's van rond de operatie kan ook na 5 jaar van belang zijn. Er is niet voor niets een termijn van 20 jaar voor dit soort gegevens.
Zie mijn bovenstaande reactie van 15:17u
Bestanden ouder dan 2017, dus ouder dan 5 jaar geleden. Vaak niet meer relevant lijkt me, maar in uitzonderlijke situaties kan het wel relevant zijn. Relevante informatie wordt vaak gekopieerd naar of genoemd in elke brief nadien. Van de meeste patienten zal de meest relevante informatie wel bekend zijn.
Bestanden ouder dan 2017, dus ouder dan 5 jaar geleden. Vaak niet meer relevant lijkt me, maar in uitzonderlijke situaties kan het wel relevant zijn. Relevante informatie wordt vaak gekopieerd naar of genoemd in elke brief nadien. Van de meeste patienten zal de meest relevante informatie wel bekend zijn.
5 jaar geleden kanker gehad?
5 jaar geleden een zwaar allergische reactie op een bepaald medicijn gehad?

Lijkt me zeer relevant!

Het gaat niet om je koopgedrag bij de lokale Jamin, het gaat om medische gegevens!
Zeer relevante informatie inderdaad, maar dit soort informatie wordt altijd overgenomen in recentere brieven (als de patient na die periode nog een keer op de polikliniek is geweest of opgenomen is geweest). Bovendien is dit soort essentiele informatie wel beschikbaar bij de huisarts. De huisarts hoort in deze uiteraard geen backup te zijn, maar in dit geval zou dat wel een uitkomst kunnen zijn.
Werk jij in een ziekenhuis?

Nee, niet altijd zal relevante informatie worden overgenomen in recentere brieven. Ik ben met je eens dat dit wenselijk is, maar gebeuren doet het niet altijd.

Los daarvan gaat het ook om uitslagen waarvan vaak enkel een conclusie is opgenomen in de uiteindelijke brief. In zeldzame gevallen kan het relevant zijn om de volledige oorspronkelijke uitslag te zien ipv enkel de conclusie.

Dus voor gros van de patiënten is dit inderdaad echt geen probleem. Voor een individueel geval kan het theoretisch wél grote en vervelende gevolgen hebben en daarom is dit een hele kwalijke zak.

[Reactie gewijzigd door DieterKoblenz op 23 juli 2024 00:19]

Ik probeerde het alleen maar te relativeren, maar het is en blijft een kwalijke zaak.
Gelukkig heeft het voor de meeste mensen geen gevolgen.
Bestanden werden al gewist vanaf 3 jaar en 2 maanden oud, en dan door nieuwe bestanden oftewel bij mensen die wederom of nog steeds in behandeling zijn.
Oja, inderdaad. Dat is inderdaad wel een termijn dat een patient nog wel in behandeling zou kunnen zijn.
"Oude bestanden, die al jaren niet meer worden gebruikt"

Het betreft bestanden van voor 2017: lijkt me toch dat er behoorlijk wat recente jaargangen bij zijn. Hoe kunnen die al jaren niet meer gebruikt zijn.
Het ging hierbij om bestanden waarvan de arts dacht dat ze nooit meer nodig zouden zijn
Hadden ze bijna goed gedacht, en hebben ze toch 5 jaar gelijk gehad (en dat voor het enkele geval). Best netjes eigenlijk.
Kan iemand mij vertellen hoe dit technisch een data lek is? Er is geen data gelekt. Alleen maar weggehaald.
De AVG zegt ook dat onbeschikbaarheid van data wat potentieel nadelige gevolgen heeft voor de betrokkene als datalek beschouwd moet worden.
De term datalek stamt uit het pre-AVG tijdperk, toen er in Nederland nog de Wet Meldplicht Datalekken was. Toen ging het alleen om het daadwerkelijk lekken.

De AVG noemt de term datalek nooit, en spreekt over 'inbreuken'. Een inbreuk kan zowel zijn in de beschikbaarheid, integriteit en de vertrouwelijkheid, waarvan die laatste overeenkomt met de oude definitie van datalek.

De media en sommige experts blijven echter de term datalek gebruiken, waardoor elke keer weer dit soort verwarringen ontstaan.

Dit is dan ook technisch, strikt, of hoe dan ook gezien GEEN datalek, maar wel een (meldplichtige) inbreuk.

UPDATE: Het AP gebruikt de term nog wel. Dus volgens hun definities is dit WEL een datalek.

[Reactie gewijzigd door RvdDungen op 23 juli 2024 00:19]

Ik moet mijzelf enigszins corrigeren.
Het AP gebruikt ook nog steeds de term datalek, en heeft gekozen voor een uitleg over wat de term precies betekent binnen de AVG. Daarbij geeft zij ook aan dat de term helemaal niet in de AVG voorkomt.

Ik denk dat het AP bewust gekozen heeft voor het intact houden van de term nadat deze enigszins al ingeburgerd was. "Datalek" klinkt natuurlijk ook spannender dan "inbreuk".

[Reactie gewijzigd door RvdDungen op 23 juli 2024 00:19]

Als er een gat in je emmer water zit ben je ook je water kwijt; dit valt er ook onder. :) ;)

* Illegal_Alien duikt weg voor de mensen die dit geen goede vergelijking vinden. :+
De fout kwam aan het licht toen een behandelaar de historische gegevens van een patiënt wilde inzien, maar een nieuwer document tegenkwam. Dit bleek in de plaats gekomen te zijn van de oude scan.
Denk dat het meer gaat over het tonen van andere documenten dan over het verdwijnen. Al is het niet helemaal duidelijk of het nu van een andere patiënt was (neem aan van wel).
De opmerkelijkste zin in dit artikel "maar werden per ongeluk overschreven ". Op dat niveau en situatie is dit gewoon een fout. Je mag vewachten dat de veantwoordelijke uitvoerder weet wat hij/zij doet en waaraan die werkt. Het woord backup krijgt o nooit betekenis laat staan de handeling. Triest
Ook de allerbeste mensen maken wel eens een fout. En ook al heb je nog zoveel kwaliteitscontroles en -processen, er kunnen altijd situaties voorkomen die niemand heeft voorzien. Als dat wel zo zou zijn zouden er nooit meer dingen fout gaan.

De RCA zal aantonen wat er fout is gegaan. Pas als de lessons learned niet worden verwerkt in nieuwe werkprocessen dan hebben de mensen die het werk doen een probleem.
Hopelijk was het niet de piloot die een fout maakte vannochtend |:(
Er is melding gedaan bij de Autoriteit Persoonsgegevens, omdat er strikt genomen sprake is van een datalek. Het ziekenhuis benadrukt dat de documenten niet kwijt zijn, maar niet meer bestaan en dat ze nooit 'in verkeerde handen zijn geweest'.
Daarom is het ook een meldplichtige inbreuk op de beveiliging van de persoonsgegevens. De term "datalek" staat niet in de AVG en wekt de suggestie dat de meldplicht veel beperkter is in scope als vaak wordt aangenomen.
Correct. De gangbare eis in data-beveiliging is dat documenten voor de juiste gebruikers beschikbaar zijn.Dat werkt dus twee kanten op. Een Denial-of-Service is ook een probleem, en dit is een onopzettelijke Denial-of-Service.
Zeker, ik was al aan het zoeken naar dit commentaar. Ik vind het ook vervelend dat media de term datalek blijft gebruiken, waaronder Tweakers hier nu weer. Dit is geen datalek, dit is een inbreuk in de beschikbaarheid van persoonsgegevens.

De term datalek stamt af van de Wet Meldplicht Datalekken die voor de AVG van kracht was in Nederland actief is geweest. Toen ging het enkel om daadwerkelijke lekken, namelijk een inbreuk in de vertrouwelijkheid. In de AVG gaat het om inbreuken in de beschikbaarheid, integriteit en/of de vertrouwelijkheid van persoonsgegevens.
De media gebruikt die term misschien, maar het ziekenhuis en AP in kwestie hebben dat zelf zo genoemd. Zie daarvoor het bericht in het gelinkte topic: Albert Schweitzer ZH honderdduizenden bestanden kwijt
Toch hadden de documenten bewaard moeten blijven. Pas als ze twintig jaar oud zijn, mogen wij medische gegevens van patiënten vernietigen. Wij hebben ongewild de wet overtreden en dat spijt ons. De Autoriteit Persoonsgegevens (AP) beschouwt het verloren gaan van de documenten als een datalek, waarover wij verantwoording moeten afleggen. Uiteraard willen wij ook u informeren over wat er is misgegaan en wat dit voor u betekent. Hieronder leggen we dit uit.
Ben verder niet thuis in dit geheel. Wellicht is het zo dat er enkel een meldpunt datalekken is en dus ook deze kwesties daaronder gemeld moeten worden. Of het dan woordelijk een datalek is kan je over discussiëren.
Ik heb het even opgezocht, en het AP gebruikt zelf bewust nog de term "Datalek", ook op hun websites. Bij de uitleg van een datalek zeggen ze ook dat de wet deze term helemaal niet kent en gaan ze vervolgens uitleggen dat het eigenlijk een inbreuk betreft.

Ergens begrijp ik wel dat het AP deze keuze gemaakt heeft (datalek klinkt spannender en was al ingeburgerd in Nederland), maar ik vind het wel verwarrend en het zorgt er voor dat bedrijven sommige inbreuken niet correct opmerken onder het mom "Dit is geen datalek".

Een beetje hetzelfde als zeggen "De aankoop van een tafel moet je melden" en dan ook verwachten dat mensen de aankoop van stoelen via hetzelfde meldpunt melden. Beide meubels (inbreuken), maar toch wel iets wezenlijks anders.
Voor medische gegevens is de meldplicht een stuk uitgebreider, o.a. dus bij "verlies", met name omdat het fijn is om te weten of iemand bijvoorbeeld een prothese heeft waardoor die niet in een MRI scanner mag.

Dus in dit geval zal er dus samen met de betroffen patiënten en behandelaars een dossier reconstructie gemaakt moeten worden in selecte gevallen waar er een groot risico op gezondheidsschade wordt ingeschat.
Het zou eventueel nog steeds een datalek in de meest gebruikelijke zin kunnen zijn.

In het artikel staat dat de arts bij het opvragen van oude documenten recentere documenten kreeg, omdat de oude documenten overschreven waren.
Wanneer dat nieuwere documenten van dezelfde patiënt waren, is het geen probleem. Wanneer het documenten van een andere patiënt waren, is er sprake van een datalek, omdat de arts daar geen toegang toe had mogen hebben. (Afhankelijk van of documentnamen per patiënt worden toegekend, of 'willekeurig', bv. op volgorde van creatie.)
Ik ben erg benieuwd naar de uitleg van Chipsoft; is dit een lokale fout geweest of is het breder dan dit en betreft het inderdaad álle ziekenhuizen die met Chipsoft werken?

Het artikel lijkt te reppen over alleen een onderzoek door Chipsoft en Albert Schweizer-ziekenhuis (ASZ).
Als dit breder is kan je binnen niet al te lange tijd meer van dit soort nieuwsberichten verwachten. Lijkt me sterk dat ASZ het ziekenhuis is met de meeste opgeslagen bestanden als ze pas vanaf 2017 klant van Chipsoft zijn.
"Deze fout had zich niet mogen voordoen en kan zich niet meer opnieuw voordoen."

Je kunt ze niet nog een keer verwijderen nee :)
Sowieso is deze 100% garantie dubieus...
Als iets 20 jaar bewaard moet worden, dan maak je toch backups voor 20+ jaar...
Ja, neem aan dat je ook minimaal voor elk jaar een jaar backup (roep maar even Tape voor de gein.) hebt; dus in het ergste geval ben je maximaal 1 jaar aan gegevens kwijt?

Op dit item kan niet meer gereageerd worden.