Albert Schweitzer ZH honderdduizenden bestanden kwijt

[equit1986]

Hoi,

Mijn ouders kregen de volgende mail binnen:

Geachte patiënt van het Albert Schweitzer ziekenhuis,

Met dit bericht moeten wij u helaas meedelen dat één of meer oude documenten uit uw medisch dossier per ongeluk zijn verwijderd. De digitale bestanden zijn onbedoeld overschreven door nieuwere bestanden. We kunnen de oude documenten niet meer terughalen. Het gaat om bijvoorbeeld verwijsbrieven, onderzoeksresultaten of aantekeningen van de behandelaar. Ze zijn van vóór september 2017 en sindsdien niet meer gebruikt voor uw behandeling.

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.

Voordat we aan de vrij uitgebreide toelichting beginnen, willen we drie belangrijke zaken benadrukken
• De documenten zijn niet kwijt, maar ze bestaan niet meer
• De documenten zijn nooit in verkeerde handen geweest
• Het gaat om gegevens die we al meerdere jaren niet meer gebruikten

Wat vooraf ging
In september 2017 is het Albert Schweitzer ziekenhuis overgestapt van een papieren patiëntendossier naar een elektronisch patiëntendossier (EPD). Iedere arts heeft toen voor iedere patiënt beoordeeld welke gegevens uit het papieren dossier moesten verhuizen naar de digitale omgeving, om de behandeling goed te kunnen voortzetten. Alle papieren waarvan de arts inschatte dat ze nooit meer nodig zouden zijn, werden niet overgezet naar het EPD. Maar ze mochten nog niet worden vernietigd. Daarom hebben wij (miljoenen) papieren documenten ingescand en opgeslagen in een digitaal archief. De originele stukken werden volgens de regels vernietigd. De scans bleven gekoppeld aan het EPD van de patiënt. Ze konden in theorie nog worden bekeken door de arts. Maar dat gebeurde in de praktijk zelden.

Wat er misging
Sinds september 2017 worden alle nieuwe, actuele documenten digitaal toegevoegd aan het EPD. Bij het opslaan van zulke nieuwe gegevens, zijn als gevolg van foute instellingen volgnummers (bestandsnamen) gebruikt die óók in gebruik waren bij de oude, inactieve bestanden. Deze laatste werden daardoor overschreven. Dit is gebeurd in de periode november 2020 tot oktober 2021. Pas na bijna een jaar werd het ontdekt, doordat toen een behandelaar toch nog eens keek in historische gegevens van een patiënt en daarbij een nieuwer document tegenkwam. Dit bestand was in de plaats gekomen van een oude scan. Zo kwam de fout aan het licht.

Wat we daarna gedaan hebben
• We zijn samen met EPD-leverancier Chipsoft een diepgaand onderzoek begonnen naar de oorzaak en de omvang
• We hebben het incident direct gemeld aan de AP
• Zodra we wisten wat er misging, is dit in het systeem meteen hersteld
• We zijn nagegaan welke documenten weg waren, bij welke patiënten deze hoorden en of ze wellicht nog teruggehaald kon worden
• Alle nieuwe bestanden die ten onrechte in het oude archief waren beland, zijn daar weer verwijderd
• We hebben samen met medisch specialisten beoordeeld of er gevolgen zouden kunnen zijn (geweest) voor behandelingen die ten einde, of nu nog gaande zijn

De eindsituatie
Al deze acties hebben veel tijd gekost. Nu hebben we de situatie goed in beeld:
• Er zijn circa 513.000 oude documenten permanent verdwenen, van in totaal circa 212.000 patiënten
• Deze fout had zich niet mogen voordoen en kan zich niet meer opnieuw voordoen
• Van alle nieuwe, actuele documenten die ongewild de plaats van de oude innamen, is niets verloren gegaan
• Alle betrokken documenten zijn nooit buiten de beveiligde digitale ziekenhuisomgeving geweest
• Het datalek heeft alleen betrekking op het niet kunnen nakomen van de bewaarplicht, andere wetten en regels zijn niet overtreden

Wat dit voor u betekent
Wij lichten alle patiënten persoonlijk in van wie onterecht en onbedoeld bestanden verloren zijn gegaan. Voor u is dat het geval. Wij bieden daarvoor onze excuses aan. Het gaat om informatie die in 2017 al niet meer van belang werd geacht voor uw behandeling. 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.

Wat u kunt doen
• U kunt in MijnASz zien van welk type en uit welke periode uw verloren gegane documenten zijn. Log hiervoor met DigiD in op www.mijnasz.nl
• Als u denkt dat u mogelijk enig nadeel ondervindt of nog zult ondervinden, verzoeken wij u om ons dit te laten weten via e-mailadres [e-mail]
• Denkt u eventueel toch dat er gevolgen zijn voor uw behandeling, bespreek dit dan met uw arts

We hebben er alles aan gedaan om de impact te beperken en het incident zo snel en goed mogelijk op te lossen. Hiervan brengen wij verslag uit aan de AP, die er een oordeel over zal vellen.

Nogmaals benadrukken we hoezeer het ons spijt dat er niet zo zorgvuldig is gehandeld als u van ons mocht verwachten.

Hopend u hiermee voldoende te hebben geïnformeerd,

Met vriendelijke groet,

Drs. Peter E. van der Meer
voorzitter Raad van Bestuur
Albert Schweitzer ziekenhuis

Goed uitgelegd, maar wel heel lullig moet ik zeggen.
De softwaremaker zou hier echt eens achter zn oren moeten gaan krabben....

[Brahiewahiewa]

equit1986 schreef op maandag 21 maart 2022 @ 13:21:
...
De softwaremaker zou hier echt eens achter zn oren moeten gaan krabben....

Misschien roept die softwaremaker al jarenlang tegen het ziekenhuis: "jullie moeten back-ups maken!" maar zei het ziekenhuis steeds: "te duur"

[Houtenklaas]

Brahiewahiewa schreef op maandag 21 maart 2022 @ 15:09:
[...]

Misschien roept die softwaremaker al jarenlang tegen het ziekenhuis: "jullie moeten back-ups maken!" maar zei het ziekenhuis steeds: "te duur"

Dat is zeker een optie, maar je gaat als softwaremaker er ook vanuit dat alle maatregelen die genomen zijn kunnen falen. En dat je dus NOOIT een bestaande bestandsnaam overschrijft. Zelf gebruik ik vaak een datum/timestamp om in de bestandsnaam op te nemen om het uniek te maken, die kan je ook simpel weer onderdrukken bij het laten zien ervan. Maar hier is dat "Too littel, too late" begrijp ik ....

[superduper]

Brahiewahiewa schreef op maandag 21 maart 2022 @ 15:09:
[...]

Misschien roept die softwaremaker al jarenlang tegen het ziekenhuis: "jullie moeten back-ups maken!" maar zei het ziekenhuis steeds: "te duur"

Dat is niet het punt. Als ik het zo lees waren de dossiers gekoppeld, maar heeft het EPD een beperkte/verkeerde nummeringsstrategie en wordt zo de boel in een rollend principe overschreven. Dat kan je natuurlijk de huizen niet aanrekenen. Ik vermoed ook dat dit per dossier anders verloopt en je dus meerdere (veel) backups zou moeten terugzetten, en de database repareren.

Maar dan nog heb je het probleem niet opgelost met de hernummering, dus blijf je bezig. Chipsoft heeft gewoon niet op tijd het max aantal dossierelementen opgehoogt

[Brahiewahiewa]

superduper schreef op maandag 21 maart 2022 @ 15:15:
[...]


Dat is niet het punt. Als ik het zo lees waren de dossiers gekoppeld, maar heeft het EPD een beperkte/verkeerde nummeringsstrategie en wordt zo de boel in een rollend principe overschreven. Dat kan je natuurlijk de huizen niet aanrekenen. Ik vermoed ook dat dit per dossier anders verloopt en je dus meerdere (veel) backups zou moeten terugzetten, en de database repareren.

Maar dan nog heb je het probleem niet opgelost met de hernummering, dus blijf je bezig. Chipsoft heeft gewoon niet op tijd het max aantal dossierelementen opgehoogt

Dat ontken ik ook niet. En het zal ook een heel onbenullig foutje zijn geweest. Bijvoorbeeld iemand die de .conf file wel ge-edit had, maar vergeten is om het comment sign ";" voor de regel weg te halen.

Maar daarnaast is er iemand verantwoordelijk voor de back-ups. En nu blijken die back-ups onvoldoende geregeld. En wij weten niet of dat komt doordat die back-ups er helemaal niet waren of dat het komt doordat ze er wel waren maar niet te restoren.
Wij weten ook niet wie er verantwoordelijk was voor die back-ups. Juridisch gesproken ligt die verantwoordelijkheid bij het ziekenhuis, want die hebben de bewaarplicht. Of en aan wie ze die verantwoordelijk hebben uitbesteed weten we dan weer niet

[superduper]

Brahiewahiewa schreef op maandag 21 maart 2022 @ 15:31:
[...]

Dat ontken ik ook niet. En het zal ook een heel onbenullig foutje zijn geweest. Bijvoorbeeld iemand die de .conf file wel ge-edit had, maar vergeten is om het comment sign ";" voor de regel weg te halen.

Maar daarnaast is er iemand verantwoordelijk voor de back-ups. En nu blijken die back-ups onvoldoende geregeld. En wij weten niet of dat komt doordat die back-ups er helemaal niet waren of dat het komt doordat ze er wel waren maar niet te restoren.
Wij weten ook niet wie er verantwoordelijk was voor die back-ups. Juridisch gesproken ligt die verantwoordelijkheid bij het ziekenhuis, want die hebben de bewaarplicht. Of en aan wie ze die verantwoordelijk hebben uitbesteed weten we dan weer niet

Ik zie echt niet hoe je dit met backups had kunnen oplossen. je maakt backups van je hele dossieromgeving en je komt een jaar achter dat er een process al ruim een jaar bestanden aan het opeten was. Dat wordt nogal een compexe recovery als je én nieuwe input, en alle oude dossiers wilt behouden, opnieuw mergen én ervoor zorgen dat de software niet gewoon opnieuw begint met 'recyclen'.

reken er ook maar op dat dit soort software niet draait met een simpel conf bestandje waar Henk van IT op vrijdag even in zit te editten (als zou me het ook weer niet enorm verbazen )

[Brahiewahiewa]

superduper schreef op maandag 21 maart 2022 @ 15:39:
[...]


Ik zie echt niet hoe je dit met backups had kunnen oplossen. je maakt backups van je hele dossieromgeving en je komt een jaar achter dat er een process al ruim een jaar bestanden aan het opeten was. Dat wordt nogal een compexe recovery als je én nieuwe input, en alle oude dossiers wilt behouden, opnieuw mergen én ervoor zorgen dat de software niet gewoon opnieuw begint met 'recyclen'.

Hmmz, ze hebben wel achteraf een reconstruktie kunnen uitvoeren; klinkt als een log-file waarin werd bijgehouden welke bestanden opnieuw werden weggeschreven. Die log-file is eenvoudig te bewerken tot een filter waarmee je de juiste bestanden kunt restoren. Zo niet, dan mankeert er toch echt iets essentieels aan je back-up procedures

reken er ook maar op dat dit soort software niet draait met een simpel conf bestandje waar Henk van IT op vrijdag even in zit te editten (als zou me het ook weer niet enorm verbazen )

reken maar dat er bij dit soort systemen lang niet altijd een GUI is om dat soort parameters te configureren ;o)

[Rukapul]

superduper schreef op maandag 21 maart 2022 @ 15:39:
[...]


Ik zie echt niet hoe je dit met backups had kunnen oplossen. je maakt backups van je hele dossieromgeving en je komt een jaar achter dat er een process al ruim een jaar bestanden aan het opeten was. Dat wordt nogal een compexe recovery als je én nieuwe input, en alle oude dossiers wilt behouden, opnieuw mergen én ervoor zorgen dat de software niet gewoon opnieuw begint met 'recyclen'.

In dit geval niet zo heel ingewikkeld. Uit het artikel blijkt dat ze al het nieuwe onterecht gekoppelde konden fixen.

Om de oude bestanden terug te plaatsen had elke backup tussen 2017 en november 2020 gebruikt kunnen worden.

Blijkbaar wordt er van het archief geen back-up gemaakt.

[F_J_K]

Brahiewahiewa schreef op maandag 21 maart 2022 @ 15:31:
En het zal ook een heel onbenullig foutje zijn geweest. Bijvoorbeeld iemand die de .conf file wel ge-edit had, maar vergeten is om het comment sign ";" voor de regel weg te halen.

Wij weten ook niet wie er verantwoordelijk was voor die back-ups. Juridisch gesproken ligt die verantwoordelijkheid bij het ziekenhuis, want die hebben de bewaarplicht. Of en aan wie ze die verantwoordelijk hebben uitbesteed weten we dan weer niet

Klant is sowieso verantwoordelijk. Maar dat neemt niet weg dat de leverancier aansprakelijk kan zijn voor schade. Ik zou dit scharen onder grove schuld Juist als het met een puntkomma in een .inf zou zijn te doen. Er kan toch gewoon geen scenario zijn waar een teller teruggaat naar nul? Dat weten we al sinds voor het millenniumprobleem

Het gaat niet 'gewoon' om backups maken en checken. Het gaat om ook voldoende stokoude backups bewaren. Zeg naast dagelijkse backups een full backup per maand voor het afgelopen een jaar + een full backup per jaar voor de afgelopen 10 jaar. En ja, zou goed zijn als ze dat wel hebben. Al was het omdat ransomware zegmaar ook een ding kan zijn.

[bbstreams]

er zijn dus weer heel wat babies geboren op 1 1 1970 ? LOL

wat een domme fout, iedereen weet dat je tenminste 1 kopie moet hebben in cold storage anders is het geen backup systeem.

[F_J_K]

bbstreams schreef op maandag 21 maart 2022 @ 21:59:
wat een domme fout, iedereen weet dat je tenminste 1 kopie moet hebben in cold storage anders is het geen backup systeem.

Hmja. Is dat in dit geval zo? Ongeacht de bug? Die kon per uur, week, dag, maand, kwartaal, jaar optreden als de bug net anders werkte. Is het realistisch om, ongeacht de hoeveelheid data, bijv. 120 full backups te bewaren? Je hebt immers geen idee wanneer het probleem begon en wanneer het wordt ontdekt.