Maasstad Ziekenhuis in Rotterdam ligt plat door grote ict-storing na noodtest

Het Maasstad Ziekenhuis in Rotterdam heeft last van een grote ict-storing. Daardoor is de spoedeisende hulp dicht en heeft het afspraken en operaties afgezegd. Een woordvoerder zegt dat er geen sprake is van ransomware of een andere soort cyberaanval.

Het ziekenhuis waarschuwt op zijn website dat het praktisch niet operationeel is vanwege een ict-storing. Patiënten kunnen niet terecht bij de spoedeisende hulp of de poliklinieken. Ook e-consults zijn niet beschikbaar en de elektronische patiëntendossiers zijn niet inzichtelijk. Daarnaast is het ziekenhuis telefonisch slecht bereikbaar.

Een woordvoerder van het ziekenhuis zegt tegen Tweakers dat het probleem ontstond door een continuïteitsoefening bij het testen van de noodstroom. Het ziekenhuis is geen slachtoffer van een ransomware- of andere soort aanval en er liggen dus geen patiëntgegevens op straat, zegt de woordvoerder.

Het Maasstad Ziekenhuis in Rotterdam. Bron: Redactiemaasstadziekenhuis

Reacties (108)

[Mrkoekie]

Problemen zijn grotendeels verholpen: https://www.maasstadziekenhuis.nl/nieuws/ict-storing-maasstad-ziekenhuis

Update 2-7-2026 08.00 uur

De ICT-storing is voor een groot deel verholpen.

Er is vannacht hard gewerkt, maar nog niet alles werkt zoals wij dat graag zouden willen. 

Bent u niet gebeld, dan gaat de afspraak door.

Houd deze pagina in de gaten voor de laatste updates.

[Rover88]

En daarom doen ze bij ons in het ziekenhuis de jaarlijkse noodstroomtest buiten kantooruren. Je wil nog wel eens tegen onvoorziene zaken aanlopen, en dan heeft het minder impact op de zorg.

Aan de andere kant is dit wel weer een goede oefening voor de afdelingen of zij hun noodprocedures op orde hebben.

[ballo50]

Volgens rijnmond.nl is de test ook afgelopen nacht uitgevoerd. De gevolgen zijn alleen vele malen groter dan initieel gedacht: https://www.rijnmond.nl/n...n-onzekerheid-over-morgen

[Rover88]

Ah sorry, ik zag de eerste berichten vanuit het ziekenhuis in de ochtend staan en ging ervan uit dat ze toen de test hadden gedaan.

[Schway]

Ik weet niet veel van ziekenhuizen, maar wat gebeurt er met de patiënten als jullie buiten kantooruren sluiten?

[djunicron]

Het buiten kantooruren is vooral zodat er niemand in liften en in andere beveiligde delen van het pand wordt opgesloten. Voor het geval de noodstroom niet tijdig opgepakt wordt, of het terugschakelen naar reguliere stroom niet gaat.

Er is natuurlijk een uitgebreide noodstroom go/no-go check. Spoed operaties kunnen altijd plaats vinden. Daar wordt vanzelfsprekend geen enkel risico mee genomen.

Voor de verblijvende patiënten kan gewoon worden gezorgd. Het kan ook juist worden gebruikt voor een crisiswerkwijze test. Alles op papier dus en dan later het dossier weer bijwerken. (Ruim) Buiten kantooruren zijn de Poliklinieken dicht. Als de kans op nood imaging (CT, MRI etc) in de opgenomen patiëntengroep heel laag / nihil zijn, kan dus rustig even 15 minuten de stroom eraf.

Wat het Maasstad hier nu heeft gevonden is dus precies wat je wilt vinden, waar je de test voor doet. Nu hebben ze deze storing op een zo laag mogelijk risico-moment. Nog steeds onwenselijk natuurlijk. Maar nu kan er gewerkt worden aan een oplossing waarbij dit NIET nog eens gebeurt. Het moment dat het langer dan X uur gaat duren (vrij ruim) dan gaan er wel extra problemen ontstaan met dingen op UPS-sen, zoals koelkasten met medicatie, pompen op accu, etc. Zo'n lange uitval is dus nog steeds wel stress...

Bron; in m'n vorige werk aan de coördinatie van dit soort testen meegewerkt, en er twee meegemaakt.

[matbie]

Het probleem is gek genoeg niet helemaal dat de stroomvoorziening niet meer opstart, maar er gaat iets mis met het netwerk. Pc's doen het op veel plekken, echter kan men niet inloggen in het systeem en moet dus alles op papier. Is nog steeds gaande overigens...

[Rover88]

Die gaan in de vriezer en worden de volgende dag weer ontdooit

Haha nee de zorg gaat uiteraard 24/7 door, maar voor het ondersteunende personeel zijn er wel gewoon kantooruren.

[mhagreis]

Die gaan in de vriezer en worden de volgende dag weer ontdooit

dankje

[jesse!]

Die kunnen altijd opgevangen worden in andere ziekenhuizen in de buurt waar nodig.

[tucker88]

Dat valt nog te bezien, want zoveel bedden zijn er niet 'extra' in Rotterdam. Dus het woord 'altijd' zou ik niet durven gebruiken.

Er zijn inderdaad nette procedures voor dit soort grote oefeningen. Zelf werk ik in één van de ziekenhuizen in Rotterdam (niet het Maasstad) en wij houden er rekening mee dat we voor een tijdje over moeten op papier. Dit wordt RUIM van te voren aangekondigd, voorbereid, klaargelegd, uitgelegd én gepland. Zodanig dat alleen die patiënten in het ziekenhuis verblijven die er ook absoluut moeten zijn. Voor het merendeel van onze patiënten en rekening houdend met het tijdstip van de oefening is dat meestal niet zo'n ramp: er gebeuren vaak ook uren niets waarvoor we de computer per se nodig hebben.

Ook zijn er procedures voor wanneer de noodstroom onverhoopt niet inschakelt: vooral een uitdaging voor patiënten die afhankelijk zijn van apparatuur (denk aan beademing, ECMO, ...)

Naast noodstroomtest hebben we ook af en toe dat het elektronisch patiëntendossier een update krijgt. Dat gaat ook soms gepaard met haperingen. We houden er meestal wel rekening mee.

[jesse!]

Naast Rotterdam zijn er nog ziekenhuizen in Zwijndrecht, Sliedrecht, Gorinchem, Utrecht, Nijmegen, Breda, Roosendaal, Duitsland, etc, etc. Als er echt iets is dan kan je echt wel ergens terecht. Het is niet dat ze mensen maar dood laten gaan

[r03n_d]

Wij hadden toevallig van de week ook een noodstroomtest, om 6u 's ochtends. Normaliter merk je er niks van behoudens deuren die dichtvallen en liften die in storing gaan. Deze keer klapte een groot deel van de groepenkast van onze vleugel eruit en werkte de noodstroom op een poli niet. Toen de werkzaamheden gestart moesten worden op de poli waren de problemen snel opgelost.

Zo zie je maar, goed om dit afentoe te testen. De ene test is de andere test niet, bewijst ook dit nieuwbericht weer.

[Guru Evi]

Het grootste probleem dat wij zien is dat mensen altijd maar meer stroom (en netwerk) nodig hebben in de kantoren. Tegenwoordig komt elke beeldvormende modaliteit ook met een werkstation met 2-4 RTX6000 Pro GPUs waar vroeger dit soort visualisaties grotendeels 'elders' (op het datacenter/server) gedaan werd of voor MRI en CT waren dit warempel stapels aan ingebouwde FPGAs in een rack met genoeg stroom. En waar je vroeger een hele reeks systemen had op dezelfde zekering, moet je nu een zekering per werkstation (wat nagenoeg nooit gedaan/aan gedacht wordt).

Als ze allemaal samen 'aangaan' en zoals de techniekers zeggen "de vliegmachine opstart" kan ik wel zien waar er volledige groepen uitklappen. En zowel aan de "Desktop"-kant als aan de bouwvakkers-kant is er niemand die denkt wat een 2.5kW voeding nodig heeft, alhoewel ze die vraag bijna nooit stellen. Siemens en GE beginnen langzaam aan aan te geven tijdens de projecten dat ze meer stroom vreten, maar de "elektrieker" zegt dat dit wel allemaal los loopt, want alle andere projecten hebben maar een zekering per kamer. En dan zeg ik dat ze indien ze niet willen herbouwen in de volgende 10 jaar, beter plannen maken voor krachtstroom en fiber.

[Reactie gewijzigd door Guru Evi op 1 juli 2026 17:50]

[hans_debruin]

Om die reden zet ik veel van dit soort apparatuur op een UPS. Dan gaat het toch wat soepeler. Vaak genoeg meegemaakt dat na een noodstroomtest de PSU defect is.

Nadeel is wel de loodaccu's die maar 3 jaar mee gaan. Ik heb helaas nog nergens een UPS met lithium of zoiets kunnen vinden. Ik snap niet waarom die er nog niet zijn.

[Yoshi]

https://www.se.com/us/en/product/SMTL1500RM3UC/apc-smartups-line-interactive-1500va-lithiumion-rackmount-3u-120v-6x-nema-515r-outlets-smartconnect-port+smartslot-short-depth-avr-lcd/

Die loodbatterijen hebben overigens ook gewoon voordelen btw.

[Niemand_Anders]

Inderdaad goed om te testen, maar waarom zou je zo'n test niet om zondag ochtend doen? Mocht er een probleem ontstaan, dan heb je niet honderden mensen in je nek hijgen wanneer ze weer aan het werk kunnen. Ook zullen dan een aantal afdelingen gesloten zijn waardoor de impact ook lager is...

[r03n_d]

Waarschijnlijk komen dan ook niet alle eventuele problemen niet aan het licht tot afdelingen weer gebruikt worden. Een elektricien zal niet aan medische apparatuur mogen/gaan zitten om te kijken of ze nog werkt of niet.

[mutsje]

Gebeurd bij ons elke maand zo'n test op vaste dag en personeel is gewoon aanwezig en erop ingesteld. Het is een vaste routine en werkt uitstekend. Hierdoor komen er soms zaken naar boven die gelijk opgepakt worden.

[Arhan]

Tja, ziekenhuizen werken niet met kantoor uren. Dat is een 24 uurs business...

[moonlander]

Het ziekenhuis is geen slachtoffer van een ransomware- of andere soort aanval en er liggen dus geen patiëntgegevens op straat, zegt de woordvoerder.

Had dat er nou perse bij gemoeten? Er staat toch duidelijk dat het gebeurde tijdens testen van de noodstroom.

[The Realone]

Wat is precies het probleem van dat erbij te vermelden? Hoevaak hebben we de laatste jaren niet mogen horen dat een simpele "storing" uiteindelijk een datalek van jewelste bleek te zijn? En hoe vaak zijn organisaties wel niet betrapt op het verdoezelen van probleem?

[R_Zwart]

Als je het er niet bij zet zijn er altijd wel weer een paar complotdenkers die denken dat er iets onder de pet wordt gehouden.Nu zullen die er ook zijn en denken dat ze een afleidingsmanoeuvre voor een grote hack hebben bedacht...

[biteMark]

Helaas is iets stilhouden in veel gevallen niet altijd complotdenken gebleken maar complotpraktijk. Er is sommige bedrijven veel aan gelegen om narigheid stil te houden dus de gedachte is soms zo gek nog niet. In het geval van ziekenhuizen mag je echter verwachten dat ze geen spelletjes spelen.

[Guru Evi]

De eerste vraag op gelijk welke brug tegenwoordig is: "is het een aanval".

[biteMark]

Je kan maar beter zo duidelijk mogelijk melden dat het absoluut niet is waar mensen als eerste bang voor zijn - mits je (zoals in dit geval overduidelijk) heel zeker weet dat het dat inderdaad niet is.

[PD2JK]

Operatie geslaagd; IT systeem overleden.

Zonder gekheid, dit is de enige manier om het goed te testen. Uiteraard is het mogelijk om een complete schaduwomgeving op te tuigen, maar dat kost een bak geld, stroom, tijd en ruimte.

[Reactie gewijzigd door PD2JK op 1 juli 2026 14:44]

[djunicron]

Een volledige schaduwomgeving is niet te bekostigen voor een ziekenhuis helaas. En kan ook niet kwa stroom. Deze testen zijn juist nodig omdat het maximale wat aan infra nodig is eigenlijk altijd al op orde is.

Een heel deel van een ziekenhuis draait al op preferent netwerk en stroom. Overal waar het kritiek is, is werkelijk een nood-kopie beschikbaar. Maar dat is dus ook precies waarom zo'n test nodig is. Komt het correct op gang en kan je daarna ook weer terug. Er zit behoorlijk kans op extreem veel extra werk met een schaduw omgeving.

[Guru Evi]

Een volledige schaduwomgeving is niet nodig, maar een HA omgeving in meerdere datacentra wel en ik hoop dat de meeste ziekenhuizen dat wel hebben. Natuurlijk, er kan altijd wel iets misgaan, daarmee dat 3-way mirror een absolute noodzaak is voor je data.

Natuurlijk dat zal de desktops en lokaal netwerk niet redden, alhoewel we tegenwoordig overal UPS zetten in de netwerkkasten zodat WiFi en laptops blijven werken, maar dat duurt maar een paar minuten, genoeg om kritieke operaties stil te leggen.

[Reactie gewijzigd door Guru Evi op 1 juli 2026 17:56]

[djunicron]

Ahh, zo. Ja, er worden doorgaans 3 datacenters gebruikt. Het is vrijwel altijd Breda + Amsterdam + Eindhoven. Of twee van die en dan een kleinere, soms regionale.

Maar écht HA is het niet. Je zit jammer genoeg gezien de infra van wat er allemaal draait met een stukje rollback. En daarnaast wordt dit omwille van de kosten alleen voor de "Gold" applicaties gedaan; je ZIS, stukje diagnostiek, stukje ondersteunende data.

UPSsen voor de wifi en laptops; nee, dat is er juist vaak niet. Te duur, niet kritisch. De werkelijke relevante systemen waar men niet zonder kan zitten op een netwerk waar dit wél het geval is, maar dat is maar een fractie. De on premise servers, zijn per ziekenhuis een beetje anders ingericht. Daar is voor een deel zeker een shutdown sequence mogelijk, maar ook zeker niet voor alles.

Heb genoeg ziekenhuizen meegemaakt waar ze simpelweg een FG en ISO niet echt structureel konden betalen. Een paar megawatt aan oude servers in z'n geheel een graceful shutdown geven, is ook gewoon vaak niet te realiseren. Er moeten keuzes worden gemaakt voor wat écht belangrijk is. En nahjah, zie in dit nieuws artikel het resultaat van het jaren lang net niet goed genoeg financieren van ziekenhuizen. Jaar in jaar uit meer eisen stellen aan de infra, nieuwe wetgeving, maar geen middelen beschikbaar om het behapbaar te maken.

[Guru Evi]

Maar eenmaal je begint te moderniseren zie je wel degelijk besparingen. Wij hebben een ouder datacenter her-ingericht. Waar de ISP's binnenkwamen was vroeger 8 racks aan hardware (routers, firewall, ids, vpn allemaal met fiber, patch panelen). We kunnen vandaag met moeite een half rack en een volledig patch paneel vullen, en dat is voor meerdere ISPs met bijna een terabit aan verbindingscapaciteit, VPN voor duizenden mensen

De kostenbesparingen zijn immens, gewoon op stroom alleen al, een 10 jaar oud systeem met E5-2660 wegsmijten moet je ook niet 1:1 verplaatsen, de nieuwe CPU is tenminste 4-8x krachtiger, dus heb je 8x minder servers nodig.

En ja, dat is inderdaad wel een slag voor het IT budget, maar dat is waar het faciliteiten budget en andere budgetten moeten samenkomen - we gaan een miljoen minder uitgeven in stroom, dat is echter geen besparing, het moet ge-her-investeerd worden, maar de COO zegt maar liefst dat hij een miljoen gespaard heeft, terwijl de CIO uitgekafferd wordt om met minder rond te komen. Niet voor niets dat de lijn tussen COO, CIO, CTO en CFO niet echt duidelijk meer is voor mij, het is tegenwoordig allemaal IT. Zelfs de stethoscoop is tegenwoordig IoT.

[Reactie gewijzigd door Guru Evi op 2 juli 2026 00:13]

[RubenNL]

Wat hier getest is, is het volledig afsluiten van het stroomnet. Niet alleen de IT systemen worden hiermee getest, maar alles. Van liften tot operatierobots.

Het is onmogelijk om daar een schaduwomgeving voor te maken.

[Guru Evi]

Operatierobots en liften voor patient transport hebben wel degelijk batterijen/backup power, maar dat gaat geen uren mee, de lift heeft genoeg om aan het dichtsbijzijnde verdiep open te gaan, de robot gaat niet opeens diep in een lichaam stil komen liggen.

[Reactie gewijzigd door Guru Evi op 1 juli 2026 17:59]

[RubenNL]

Zeker, maar die batterij backup moet ook getest worden Dat is hier gedaan.

Alle critische IT systemen zou ook op een batterij backup moeten zitten, maar mogelijk is hier iets fout gegaan.

[Guru Evi]

De meeste kritische systemen hebben hoogstwaarschijnlijk (hopelijk) een UPS, maar dat is niet verzekerd, soms zijn er gewoon besparingen geweest. Maar dat wil niet zeggen dat die UPSen voor dagen blijven draaien, daarvoor zijn dieselgenerators nodig, en de dieselgenerators doen maar een klein deel van het ziekenhuis (25% van de verlichting bijvoorbeeld). Er is geen enkel ziekenhuis die een gasturbine 'op standby' heeft.

[weazle]

Mwah, wat denk je wat dit voor gebouw is?

https://maps.app.goo.gl/BnSL1jD2n3ws1G4N8?g_st=ac

[RubenNL]

De ziekenhuizen die ik heb gezien kunnen op bijna volledige capaciteit doordraaien. Absoluut alle verlichting blijft werken, maar ook vrijwel alle andere systemen.

Vaak gaat wel de helft van de liften en het grootste gedeelte van de rontgen apparatuur uit, maar er blijven altijd nog enkele werkend.

[Powergrim]

Je kan linksom of rechtsom hier wat van vinden. Maar ik vind het positief dat ze het hebben durven doen. Nu is een probleem opgespoord wat met een echte noodsituatie ook was voorgekomen. Ik hoop dat ze snel weer up komen.

[Koffie]

Noodstroomtesten in een ziekenhuis is gewoon de norm hoor.

[Mathijs Kok]

Je bent gewoon wettelijk verplicht dit soort testen te doen. Naar ik me herinner, al sinds 1970.

[Pasteis]

Een woordvoerder van het ziekenhuis zegt tegen Tweakers dat het probleem ontstond door een continuïteitsoefening bij het testen van de noodstroom.

Is dit overdag gebeurd? Want dat vind ik wel gewaagd. Zo’n scenario op klaarlichte dag testen kan voor problemen zorgen. En dat blijkt nu

[ewout.denheijer]

nee klaarblijkelijk 's nachts, maar overdag nog niet opgelost: https://www.rijnmond.nl/nieuws/2218036/problemen-ziekenhuis-nog-groter-alle-afspraken-geschrapt-spoedeisende-hulp-dicht-en-onzekerheid-over-morgen

[vrow]

Dat is maar de vraag dus. Want ze hebben het 's nachts getest en dat heeft nu dus juist voor problemen gezorgd. Hadden ze het overdag getest, was alles misschien juist wel goed gegaan!

[mjtdevries]

Aan de andere kant zou je kunnen redeneren dat je continuiteit systemen zodanig goed en betrouwbaar moeten zijn dat je dat rustig overdag zou moeten kunnen doen.

Als je dat niet durft, zijn je systemen dan wel goed genoeg?
Hoeveel vertrouwen kun je er dan in hebben dat het wel goed gaat bij een echte calamiteit?

Lang geleden beheerde ik een aantal grote exchange servers in een enterprise omgeving en daar deden we patches gedurende kantoortijd. Even een failover en dan een server patchen. We hadden per database twee kopiën en één vertraagde kopie. Dus als we één server down brachten hadden we nog voldoende redundantie over.

[Cyberpuppy]

Ligt toch iets anders. Als er een exchange onderuit gaat dan kost het hooguit een paar emails. In dit geval zou het (extreem worst case) een mensenleven kunnen kosten. Beetje lastig uiteggen aan de nabestaanden.

[mjtdevries]

Dus is het nog belangrijker dat je continuiteit goed is en dat er op kan vertrouwen dat het goed werkt. Dus zou je met nog meer vertrouwen je continuiteit test tijdens kantooruren moeten kunnen doen.

[Cyberpuppy]

Klopt, maar hoe kom je op dat punt? Verreweg de meeste ziekenhuizen zijn gewoon operationeel. Je vertrekt dus vanuit een al draaiende en bestaande situatie. Dat is vele malen lastiger dan dat je ergens een green field hebt en volledig vanaf de grond alles kunt opbouwen en ook al vanaf het eerste begin kunt testen.

Ik ben overigens wel benieuwd naar de post-mortem, want erg nieuwsgierig wat hier mis ging.

[CAPSLOCK2000]

Dat is ook mijn filosofie, overdag is iedereen fris en op z'n best. Als er toch iets miis gaat zijn andere collega's beschikbaar om bii te springen. Hoe riskanter iets is hoe vaker je het zou moeten oefenen. Helaas is dat in praktijk niet altijd mogelijk.

[D0phoofd]

Klinkt als een cold-start scenario en dat is niet tof om in te zitten. Vaak is het te herleiden naar een te grote afhankelijkheid van een of meerdere systemen die naar elkaar wijzen.

Succes met het herstel. Dit zijn taaie situaties.

[The Realone]

De definitie van een cold start is mij bekend, maar dat dit een "scenario" zou zijn is nieuw voor me. Als ik dat artikel lees, zijn dat gewoon vrij standaard zaken waar je mogelijk tegenaan loopt bij een cold start, niet echt iets waar je "in komt te zitten:".

Services hebben over het algemeen retries. En daarbij is monitoring van services ook doodnormaal, dus het lijkt me dat je prima weet wat niet draait. Dat artikel lijkt vooral over tijdelijke performance degradatie te gaan en hoewel dat er ook voor kan zorgen dat afhankelijke services daardoor niet starten, is dat geen scenario waarbij dat een halve dag later nog voor problemen zou moeten zorgen.

[anboni]

Dat is dus precies het punt wat @D0phoofd maakt: Er is NIETS. Geen services, geen retries, geen monitoring. Dat is een cold-start en da's verdomd lastig te testen of simuleren. Ze zullen vast een draaiboek op de plank hebben liggen voor dit scenario, maar iedereen die met IT of datacenter techniek op deze schaal en complexiteit in aanraking is geweest, weet dat zo'n scenario zelden overal in voorziet. (en dan heb ik het nog niet over de extra uitdagingen in de ziekenhuis-specifieke hoek, waar ik geen ervaring in heb)

[The Realone]

Ik lees in dat artikel echt niet wat jij nu schetst. Hoezo zijn er geen services? Het systeem is toch niet verdwenen? Je start een host op, en die heeft services. Als die services niet starten omdat er dependencies zijn die niet goed gestart zijn, ga je die ketting af. Als je een systeem hebt waarbij je 100 dependencies diep moet gaan voordat je bij de basis bent om één enkele dependency chain te starten, dan heb je een behoorlijk waardeloos systeem.

Daarbij, als er aan alle kanten services niet starten, is dat in de meeste gevallen te herleiden tot 1 of 2 kernservices. Denk DNS, auth, storage, etc. Dat is zeer vervelend, maar mag toch geen vele uren in beslag nemen. En het in kaart brengen van al die dependencies is voor 90% helemaal niet zo ingewikkeld, wel tijdrovend.

[D0phoofd]

Dit is zeer waarschijnlijk wel het scenario. Want - inderdaad zoals jij het schetst - zou de server en de diensten normaal moeten starten na blackout.

Echter, nu lijkt het er dus op (inderdaad - speculatief. Ik heb dit nooit feitelijk gezegd) dat het niet goed terug komt door zo'n recursive dependency of iets dergelijks.

Voorbeeld; je doet Dot1x op je switches maar je radius server is niet bereikbaar omdat je switch de vmhost niet accepteert omdat de radius niet kan reageren. Zo iets simpels kan heel je org in deen super moeilijke positsie brengen.

Vaak groeien die dingen door de jaren heen zo en is er (onbedoeld) legacy ontstaan waar geen rekening mee is gehouden of mogelijk als risico is geaccepteerd.

[The Realone]

Ja zo kun je natuurlijk scenario's verzinnen die je in de praktijk nooit tegen kan of mag komen. Een beetje van het niveau de decryption key van je password database in je password database opslaan. Dot1x op je VM switches waar je RADIUS op draait is ook van die categorie. Klopt, in theorie kun je zo vast komen zitten, maar als je daar echt ben is het bijzonder knullig.

[CPM]

Knullig misschien, hoe kom je er 100% achter? Uitproberen. Jij doet alsof je alle waarheid al in pacht hebt, en alles al voorzien hebt. Leuk in theorie, maar werkt niet zo in de praktijk. Been there done that, je kan altijd iets over het hoofd zien. Ik vind het ontzettend waardevol en moedig dat ze het zo testen, ze zullen er van Balen want de impact is groot, maar ik denk dat er heel veel ziekenhuizen willen leren van wat zij hier tegen zijn gekomen.

[Reactie gewijzigd door CPM op 1 juli 2026 22:25]

[The Realone]

Nee dat doe ik niet, maar ik mag toch wel een mening hebben over iets? Ik heb er eveneens genoeg ervaring mee, en ben soortgelijke situaties ook vaker tegen gekomen. En dan denk ik ook, wat een gepruts, ook van mezelf. Maar een situatie waarbij je zo'n enorm lange downtime hebt in een omgeving waar de belangen zo groot zijn, dat mag niet. En daar zal wel iemand verantwoordelijkheid voor (moeten) nemen.

[anboni]

Da's niet knullig, dat is de werkelijkheid. Zeker als je in een wat groter maar onderbemeten team werkt (wat voor de meeste bedrijven de realiteit is) worden niet alle implementaties perfect doordacht op dit soort scenarios. Of je bent een storing aan het troubleshooten waarbij niet alle aanpassingen perfect worden vastgelegd of er ergens een geitenpaadje wordt gepakt om het probleem nu op te lossen maar daarbij wordt over het hoofd gezien dat het in een volgende calamiteit ongewenste bijwerkingen kan hebben.

[The Realone]

Nogmaals, er zit een enorm verschil tussen wat zaken misschien, een applicatie die ergens niet start, een db die traag reageert, file shares die niet mounten, etc, en een hele omgeving voor een dag plat. Maargoed, ik denk dat de discussie wel op zijn einde loopt.

[Guru Evi]

De RTO voor zulke situaties is ook niet 15 minuten zoals sommige mensen "verwachten", voor het ziekenhuis waar ik gewerkt had was de RTO 1u-3 weken afhankelijk van het systeem, betalingen hoeven niet verwerkt te worden als de spoed niet open is en blijkbaar is de loonverwerking grotere prioriteit.

[Reactie gewijzigd door Guru Evi op 1 juli 2026 18:03]

[anboni]

Nee precies, dan ga je al gauw in uren tot MVC (Minimum Viable Company) praten.

[nextware]

Ook gelijk een goede test van het Disaster Recovery Procedure om te kijken of je RTO en RPO realistisch zijn

[M. Schaap]

Mooi, nu nog evalueren hoe dit heeft kunnen gebeuren, waarna het gedeeld kan worden met andere ziekenhuizen en vergelijkbare organisaties. Toont weer eens aan hoe nuttig het is om je noodprocedures ook daadwerkelijk periodiek te testen.

[CAPSLOCK2000]

Succes aan alle betrokkenen, fijn dat het probleem is gevonden tijdens een gecontroleerde test en niet op een echt paniek-moment.

[grizzlywilde]

Test geslaagd met bevindingen.