Ziekenhuis Enschede zegt 27 operaties af wegens ict-storing

Ziekenhuis MST in Enschede heeft vanaf vrijdagochtend te maken gehad met een omvangrijke ict-storing. Omdat de ict-infrastructuur van het ziekenhuis plat lag, konden meerdere operaties niet doorgaan. Spoedpatiënten moesten elders worden ondergebracht.

De storing begon op vrijdagochtend rond 09.00 uur. In totaal moest het ziekenhuis 27 operaties afzeggen en patiënten doorverwijzen naar bijvoorbeeld de spoedeisende hulp in Almelo. Ook werden patiënten verzocht thuis te blijven.

Volgens het ziekenhuis leverde dat geen problemen op. Medewerkers van het ziekenhuis konden niet meer met hun computers bij de systemen. Ook het telefoonverkeer lag plat en het ziekenhuis kon geen updates op de site plaatsen.

De oorzaak van de problemen is niet bekend. "Wat we wél weten, is dat er iets is gebeurd in het ict-systeem en dat de back-up niet werkte", meldt een woordvoerder tegen RTV Oost. Rond 12.44 uur, was de storing verholpen en inmiddels kan het ziekenhuis weer operaties uitvoeren en patiënten ontvangen op de Spoedeisende Hulp.

Reacties (91)

Altijd grappig om te lezen als men in de pers spreekt over 'het ict-systeem'.

Een ziekenhuis gebruikt tig systemen, in dit geval konden afspraken niet ingezien worden.
Maar als ook de telefonie niet werkt dan is er in mijn ogen veel meer mis dan een enkele verstoring.

Wanneer er ook een telefoniestoring is, kan het netwerk gerelateerd zijn. Verder heeft 'het volk' er natuurlijk niets aan wanneer er wordt gemeld component X van de ICT infrastructuur ligt eruit.

Waarom heeft het 'volk' er niets aan?

Als je onderhoud gaat uitvoeren communiceer je ook welke applicatie of netwerkcomponent je gaat updaten bijvoorbeeld. Door te roepen we gaan 'iets' doen aan het ict-systeem creeer je alleen maar verwarring.

Ik hoef als burger niet te weten welke applicatie een storing had maar iets gerichter zou wel fijn zijn want dan weet je ook wat de impact is voor jou als patient. Kennelijk heeft het ziekenhuis zijn redundantie niet voor elkaar.

Het 'volk' heeft er niets aan.

Het enige wat het 'volk' vervolgens gaat doen is conclusies trekken over onderwerpen waar ze over het algemeen niets van weten. In dit geval klinkt het als een networking issue, maar wat daar de oorzaak van is hoeft niet direct duidelijk te zijn, waardoor het niet handig is in detail te treden voordat het daadwerkelijk (na het oplossen van het issue) onderzocht kan worden.

Natuurlijk kan het een ICT faux pas zijn, maar het zou ook kunnen zijn dat iemand op de etage boven waar de core switches staan met backups, de WC heeft verstopt (iets met maandverband doorspoelen). Er lekkage is ontstaan, onderhoud aan het pand niet optimaal is geweest waardoor er toch vocht in de serverruimte terecht is gekomen en alle apparatuur heeft kortgesloten. Dan is er wellicht een ICT storing, maar niet een oorzaak die binnen het beheer van ICT ligt. En dit klinkt wellicht heel ver gezocht, maar dit gebeurt (ik spreek uit ervaring).

Verder zijn dergelijke zaken interne aangelegenheden die eerder voor extern amusement zorgen (via de media) dan dat men er extern iets aan kan doen.

Als ik slecht geïnformeerd wordt ga ik er als vanzelf vanuit dat "ze" iets te verbergen hebben.
maar ik ben dan ook heel cynisch en wantrouwig..

En als je goed geïnformeerd wordt ga je er waarschijnlijk van uit dat ze liegen odmat ze iets te verbergen hebben...

https://nl.wikipedia.org/wiki/Paranoia

Ik werk in het MST (niet op de ICT-afdeling). Wat er precies is misgegaan weet ik niet, en het is ook niet aan mij om over te communiceren, daarvoor verwijs ik naar de woordvoerders van MST. Zoals oa op de site van TV Oost staat, werkten telefonie en de inlog op de computers niet.
Ik wil wel graag ontkrachten dat er binnen MST geen sprake zou zijn van redundante IT-systemen. Deze zijn er wel degelijk (zoals ook in het bericht op TV Oost staat), zowel on-site als off-site. Waarom het niet heeft gewerkt, dat zal uitgezocht moeten worden door de experts en daar wordt ongetwijfeld een grondige evaluatie van gemaakt om te voorkomen dat dit weer voorkomt.

Waarom ze niet werken zal inderdaad wel onderzocht worden en het is iets dat je wel vaker ziet. Backup systemen die falen op het moment dat ze echt nodig zijn, en dat al te vaak omdat de failover op zich niet correct getest kan of mag worden in een productieomgeving want het moest inderdaad eens misgaan. En wanneer je dan 24/7 je diensten moet verlenen heb je niet echt een moment waarop je kan zeggen: dan doen we het.

Ik ga er verder niet al te diep op in, maar ik kan in ieder geval bevestigen dat de reactie zoals jij hem geeft niet klopt. MST heeft "gewoon" een eigen ICT afdeling. Ik heb in ieder geval nog nooit een blanke Indiër met Twents accent gezien en zo zien onze ICT-ers er toch echt uit..

[Reactie gewijzigd door geert_schrijver op 11 januari 2019 18:28]

Wil niet zeggen dat een gedeelte niet onderhouden wordt door mensen in India. En niet dat dit meteen slecht is trouwens mocht het zo zijn. Ik zie dat de IT Infrastructuur geoutsourced is naar CGI. Die partij zal zeker resources in lage loon landen gebruiken voor monitoring/onderhoud etc. Dat er ITers rondlopen wil niet meteen zeggen dat er ook geen resources in India zitten. Het is een grote organisatie.

Een beetje makkelijke conclusie om te roepen dat het ziekenhuis zijn redundantie niet voor elkaar heeft.

Welicht had het een heel andere oorzaak, een menselijke fout of een onvoorziene bug.

Nou, als het doel van redundantie is om storingen op te lossen, dan is het niet zo heel vergezocht om te stellen dat die redundantie niet in orde is.

Een beetje bot gezegd is het namelijk heel simpel:
IF !SysteemInDeLucht THEN RedundantieOK == FALSE.

ik werk ook in een ziekenhuis.. niet in het MST. en ja wij hebben de redundantie prima op orde, maar jou 'IF !SysteemInDeLucht THEN RedundantieOK == FALSE' slaat natuurlijk kant noch wal zonder op de hoogte te zijn van de juiste informatie. Wanneer bij ons alle opties om netwerktechnisch bij 'de andere kant' te komen faalt, dan kun je nogwel 6 keer redundant zijn ,maar gaat 't nog niet werken...

Het punt is dat de redundatie op papier niet genoeg is en enkel werkt als je het ook test in de praktijk.

Je kan wel denken dat je redundant bent, maar als je regelmatig je backups of failover test dan had dit niet zo grootschalig kunnen misgaan denk ik. Een beetje bedrijf heeft 4G failover als bekabeld internet uitvalt bijvoorbeeld.

Nee, klopt, en dus is je redundantie niet toereikend om het probleem op te lossen. Redundantie is - net als veiligheid - een afweging tussen kosten en baten. Uiteindelijk kun je nog zo redundant zijn, er is ALTIJD iets mogelijk dat nóg groter is dan waar je op had gerekend. Al zou je alles uit de kast trekken, als er een atoombom valt of een tsunami komt, ben je kansloos.

Daarom stond er ook bij 'een beetje bot gezegd', maar ja, nuances op internet ....

@tweaker2010 @P_Tingen

Ben het ook echt helemaal met jullie eens hoor... Probleem is dat wij hier met z'n allen de it in de zorg wel heel belangrijk vinden, maar de verschillende zorgverzekeraars toch een stuk minder. Gelukkig wordt er steeds meer geld vrijgemaakt hier voor binnen de perifere ziekenhuizen, maar je moet oppassen dat je niet ook een 'slotervaart' gaat worden. Gelukkig is 'mijn' ziekenhuis zo slim om tijd en geld te investeren in het zo goed mogelijk redundant maken van onze kernsystemen.

omdat weinigen weten wat het betekend als de ipanema er uit lag.
om maar iets te zeggen.

Bij ons houden we de gebruiker zo warig mogelijk. Dit omdat ze dan allemaal dingen gaan googlen en het dan "beter weten" dan wat wij aan het doen zijn. Dit is uitvoerig getest

Het ligt er helemaal aan bij wat voor bedrijf je werkt. Accountants bijvoorbeeld interesseert de techniek totaal niet zolang het maar werkt. Bij technische bedrijven is het personeel zelf ook technisch onderlegd en probeert men vaak ook zelf te troubleshooten of achter een probleem te komen. Dus het is niet zwart-wit.

Er is een onderscheid tussen medewerkers van het ziekenhuis en het publiek. In de ziekenhuizen waar ik heb gewerkt, wordt uiteraard goed gecommuniceerd betreffende changes en onderhoud.
Het gaat jou niets aan wat er stuk is gegaan, dat jij nieuwsgierig bent is iets anders, dat ben ik ook. Daarbij komt dit nieuws volgens mij binnen via de mainstream media, die komen niet verder dan 'ICT-problemen'.

Ik hoef als burger niet te weten welke applicatie een storing had maar iets gerichter zou wel fijn zijn want dan weet je ook wat de impact is voor jou als patient

Er staat dat ze niet kunnen inloggen en geen gebruik kunnen maken van telefonie (VOIP?), dat klinkt als een netwerk probleem. Het enige wat belangrijk is voor de patient, is of hun behandeling door gaat en of ze wel of niet naar het ziekenhuis moeten komen.
Weinig patiënten die kunnen bepalen wat de impact voor hun is wanneer bijvoorbeeld het RIS eruit ligt.

[Reactie gewijzigd door Abom op 11 januari 2019 13:47]

Meer details hebben voor leken helemaal geen zin. Als je op fora zoals Radar kijkt, zie je een paar keer een onderwerp langskomen over onveilige fittingen van slimme meters. VOor leken is dat een reden om een slimme meter te weigeren. Terwijl het probleem met alle soorten meters, en zelfs alle mogelijke fittingen voor kan komen.

Meer informatie zorgt dan alleen maar voor onnodige onrust.

Altijd grappig om te lezen als men in de pers spreekt over 'het ict-systeem'.
Een ziekenhuis gebruikt tig systemen,

En in dit geval werkte voor zover bekend vrijwel geen van die systemen. Dan mag je van mij betreft wel over 'het' ict systeem spreken. Tenslotte vormen losse systemen in een ICT terminologie een ander systeem. Vandaar dat we spreken van systeembeheerder en niet systemenbeheerder.

Eens, hoewel je ook over een landschap van systemen zou kunnen spreken. Maargoed, een landschapbeheerder klinkt ook maar verwarrend.

Ik ken dit , maar to be fair, er loopt hier niet een huismeester rond ofzo dus als ik één van mijn collega's was zou ik ook niet weten naar wie ik anders moet met mijn klacht over het tosti ijzer dus next best thing is allicht die gekke nerd die het negen van de tien ook ook wel gewoon weet.

[Reactie gewijzigd door Koffiebarbaar op 11 januari 2019 14:36]

Nou ja, in dit geval dus ook werkelijk het informatie- en communicatietechnologie "systeem" lol.

De patientdossiers waren niet inzichtelijk. Als alleen afspraken niet ingezien kunnen worden gaan ze geen operaties af zeggen want die worden ongetwijfeld op meerdere manier vastgelegd. Dat ze het hebben over de ict of het ict-systeem of wat dan ook is vrij logisch, meestal wordt niet exact naar buiten gebracht wat er niet functioneert.

Achjah, volgens vele gebruikers zijn batterijen en stekkerdozen ook onderdeel van ICT. Als ik een euro krijg voor elke keer dat een gebruiker aan mij vraagt of wij batterijen hebben of even wat stroom kan leggen had ik nu lekker met mijn bruine kont op de Maldiven gezeten.

verschillende mensen bij mij op het werk zeggen jij van ICT ben verantwoordelijk voor alles met een stekker, omdat je alles kan oplossen ,, dus paperjams, vast gelopen papier versnipperaars , zekeringen die eruit klappen, gedoe met privé mobieltjes , navigatie systemen ......

Maar als je aan een Cardiochirurg vraagt naar je tennisarm te kijken, is dat niet hun ding. Stomme artsen, wij ICT'ers weten gelukkig wel alles van alles...

Vertel ze de volgende keer dat je hen een kabel met een potentiaalverschil kan aanbieden.

batterijen en stekkerdozen

Hier kan ik nog in komen. Wacht maar tot je gevraagd word voor tosti-ijzers of airco

Wij hebben zelfs al meubels in elkaar gezet. Polyvalent noemen ze het dan ineens. Maar wel leuk als teambuildingalternatief

En voor een wifi kabel moet je het dubbele vragen.

Stekkerdozen niet, maar batterijen, dan bedoel ik een APC, wel.

Ook het telefoonverkeer lag plat en het ziekenhuis kon geen updates op de site plaatsen.

"Wat we wél weten, is dat er iets is gebeurd in het ict-systeem en dat de back-up niet werkte",

Even een gokje. Dit klinkt als netwerk probleem.
Hoezo zou je dan van een backup afhankelijk zijn?
Of is het dan een backup lijn?

Bij ons nemen we dagelijks backups van alle running-configs. Kunnen we makkellijk terug.
En we zitten ook veilig als iemand de config vergeet te saven, want daar kom je vaak pas maanden later achter.

Dat werkt ja, maar ik snap dat hele mechanisme niet persoonlijk. In welke use case wil je dat zo'n switch terugvalt op een andere configuratie dan waar je mee werkte pre-reboot?

In de situatie "crap ik heb per ongeluk een zwik instellingen verwijderd"

[Reactie gewijzigd door .oisyn op 11 januari 2019 15:01]

Dat lijkt me meer een gevalletje backups maken voordat je aan dingen gaat trekken.

Dat is een mogelijke usage pattern. Een andere is een expliciete save. Beide hebben hun eigen voordelen en nadelen.

Fair enough. Al vraag ik me wel af of dat tikken op save niet gewoon een automatische wordt en dus wel effectief is op die manier.

[Reactie gewijzigd door Koffiebarbaar op 11 januari 2019 18:31]

Maar als je switch zijn vorige configs ook nog zou hebben en je tijdens boot eventueel zou kunnen selecteren met welke je wenst op te starten (meest recente by default), dan heb je dat probleem ook niet. En omdat je enkel met opgeslagen configs werkt kan je nooit vergeten op te slaan.

Of als je jezelf per ongeluk buiten sluit door je eigen netwerkverbinding door te zagen

Ik vermoed dat ze de oude config niet hebben opgeslagen voordat ze aanpassingen gingen doen in de router(s)/switch

Hier kan ik me wel in vinden ja.
Ben helaas ervaringsdeskundige.
Een switch configureren en vergeten op te slaan.
Bij de reboot alles kwijt

Heb ik nooit gesnapt bij bijvoorbeeld Cisco. Dan vind ik de manier waarop Juniper het doet een stukje beter. Daar werk je niet zomaar met je running config.

Dan wordt het tijd om eens te gaan professionaliseren...

HOe is het in godsnaam mogelijk dat zoiets tot een operationeel probleem leidt? Je maakt aan het begin van een service windows een backup van de configuratie, doe vervolgens wat je moet doen, maakt per ongeluk een fout, en volgense het draaiboek zet je de oude configuratie terug en ga je kijken of er nog voldoende tijd binnen het service window beschikbaar is om de wijziging nog een keer te doen. Zo niet: einde van de klus en een nieuw service window plannen.

Helaas zijn er nog teveel cowboys in de ICT die het soort fouten maken zoals jij noemt.

Tuurlijk heb je gelijk maar.... tijdsdruk en 10dingen tegelijk moeten doen helpt ook niet echt

de tweede set van het systeem, de backup die er voor moest zorgen dat ze door konden gaan met hun werkzaamheden.

Is mijn gok in elk geval.

Vraag mij af of het dan wellicht een cryptolocker issue is. Ziekenhuizen krijgen wel vaker hiermee te maken. Tevens is er momenteel een variant bezig waarbij men de netwerken onderzoekt voor de echte aanval plaats vind zodat back-ups mee worden genomen in de aanval.

Wat de problemen ook zijn, ik hoop iig dat ze iig snel zijn verholpen!

Je krijgt een 0 rating, maar je kunt maarzo gelijk hebben. Er zijn de afgelopen weken meerdere partijen getroffen door bijvoorbeeld Bitpaymer ransomware. Ik weet dat er meerdere grote hostingpartijen daar deze week sinds afgelopen kerst last van hebben.

[Reactie gewijzigd door Zenomyscus op 11 januari 2019 13:50]

Ergens toch wel schokkend dat men dan operaties geen doorgang kan laten vinden. Hoe zit dat in noodsituaties?

Ik snap dat ze nu de luxe hebben om het zekere voor het onzekere te nemen omdat ze bijvoorbeeld niet bij de dossiers kunnen (print die dan uit een dag voor de operaties?), maar het stemt me weinig gerust als men blijkbaar zelfs voor spoedsituaties er geheel van afhankelijk is.

Ze zullen ongetwijfeld iets hebben voor noodgevallen. Maar die informatie is nooit 100% actueel/compleet, zelfs als je dat elk uur ververst. In geval van echte nood (denk: levensgevaar) dan is dat beter dan niks, maar de meeste operaties zijn gewoon gepland en die gaan dan echt niet door. Tevens zal een spoedeisende hulp 'dicht' gaan waarbij ambulances de nieuwe patiënten naar een ander ziekenhuis zullen brengen.

Kennelijk hebben ze niet iets voor noodgevallen, want de spoedpatienten moesten verplaatst worden...

Dossiers zitten zoals je zegt veelal in de computer en daar kunnen ze niet bij, voorzorg beter dan gewoon doen.

In het geval van een noodgeval zit je zo ie zo met het Triage systeem voor patiënten. Je moet er inderdaad niet aan denken dat op zo'n moment ICT eruit knalt op wat voor manier dan ook. Ze zullen proberen alles door te sturen naar andere ziekenhuizen in de buurt. De mensen die dat regelen hebben dan echt een hel, maar eigenlijk is dat ook een kick waarom je dat doet. Zo ken ik mensen die in Brussel werkten op de spoed van een ziekenhuis ten tijde van de aanslagen daar. Je doet het daar niet om en je rent je rot maar ergens halen ze daar zeker voldoening uit hun werk.

Maar in zo'n geval doen ze veel op papier en als ze echt moeten opereren doen ze dat.

Spoed ging naar een ander ziekenhuis hoorde ik op de radio. In het uiterste geval kan je wel opereren, maar heb je geen toegang tot allergieinformatie en dergelijke.

In ons ziekenhuis is dit enkele maanden geleden ook gebeurd.
Het digitaal patienten dossier platform lag uit, waardoor oa. niet 100% veilig kon nagegaan worden welke operatie moest uitgevoerd worden (knieprothese plaatsen: li of re?) en of patient allergisch was aan allerhande producten.
Bijgevolg werd besloten alle operaties die dag te annuleren.

Oei, dat klinkt niet heel positief. Hoe kan het anno 2019 nog zo zijn dat bedrijven volledig afhankelijk zijn van IT en hier geen adequate back-up voor hebben? Ik vind dat best zorgwekkend....

Raar, hier hebben we daar een noodprocedure voor. Elke nacht krijgt die een update...
Spoed zou dan wel problemen hebben, maar geplande operaties kunnen gewoon doorgaan.

Hoe bedoel je noodprocedure? Als het IT systeem uitvalt kan je toch niet veel meer beginnen?

Meestal is dat iets als een (offline) backup. Als je netwerk onderuit gaat is het toch handig als je nog bij bepaalde kritische gegevens kan.

Wij hebben in ons bedrijf ook wat noodapplicaties. Zo kun je zelfs in het geval van een stroomstoring toch bepaalde werkzaamheden uitvoeren die doorgang moeten vinden, met behulp van bijvoorbeeld laptops.

[Reactie gewijzigd door Nyarlathotep op 11 januari 2019 14:10]

Op elke afdeling staat minstens 1 pc met een noodprocedure icoon. Zodra het netwerk niet meer werkt, of maar half... kunnen ze daar op klikken. Dan start op die pc een 'noodprocedure'. Ze krijgen dan een alleen lezen versie van het EPD waar minstens alle gegevens van alle patiënten van die dag in staan.
Werkt het netwerk wel nog deels kan er een recentere versie beschikbaar gemaakt worden, of in extremis verdelen we die data via USB sticks...

niet elke pc, en enkel de patienten die op de planning staan voor de volgende dag (en).
Valt best wel nog mee. Enkele gig, met beelden en al.

Kunnen er bij dit soort ICT storingen backup systemen oid worden ingezet om meteen over te schakelen naar een werkend systeem en dat er op de achtergrond dan aan het probleem kan worden gewerkt? (totale ICT noob hier)
Ik hoor namelijk vaak ter voorkoming van storingen en dergelijke: backuppen of dubbele systemen laten draaien zodat er bij storingen of fouten meteen kan worden teruggevallen naar een (ander) werkend systeem.

Dubbele systemen dus volledig redundant werken is zeer kostbaar.
Een ziekenhuis zal dit dus maar voor een deel zo ingericht hebben.

Core dubbel uitgevoerd, server laag dubbel uitgevoerd, access laag single
Probleem is meestal dat het verouderd is en vaak geen firmware upgrades gedaan worden.
Fail-Over testen periodiek worden ook niet gedaan, dus als er dan bv een core switch uitklapt dan hoop je maar dat alles nog blijft werken....

Firmware wordt in principe wel degelijk onderhouden, anders ga je vaak van de vendor geen ondersteuning krijgen. Je gaat geen honderdduizenden euro uitgeven aan apparatuur en service contracten om dan geen updates te doen die je contract waardeloos maken en het risico op storingen vergroten.

En stel je wenst je fail-over te testen op je core in productie (dewelke in je testomgeving geen enkel probleem vertoont), wanneer ga je dat doen in een omgeving die 24/7 draait? Er is geen geschikt moment om dat te doen.

Firmware upgrades worden om die reden dus niet uitgevoerd omdat een reboot noodzakelijk is..... Moderne systemen ondersteunen ISSU en hebben daardoor minder impact en heb je dus bij een upgrade gelijk je fail over getest. Dit is geen aanname maar praktijk, ik kom bij meerdere ziekenhuizen.

sterkte!

Dit verhaal ruikt naar een issue met Eset extensions op Azure VM`s, het tijdstip van de "oplossing" matched namelijk exact met dit zelfde probleem welke een aantal klanten van ons hadden.

(Er was geen communicatie mogelijk met de eset master server, waardoor de agents out of date leken, derhalve weigerden Azure vm`s met die extension op te starten)

Wat gebeurd er dan met operaties die dan bezig zijn? Lijkt me niet fijn.

die gaan gewoon door hoor

Je hebt geen ICT systeem nodig om de operatie af te maken/voort te zetten. Afzeggen van patienten is vaak meer uit veiligheid dan strikt noodzakelijk.

Ik durf te betwijfelen dat ze in zo'n omgeving (patienten)data op Azure draaien.

ICT-Systeem is wel een heel omvangrijke manier om de schuld ergens op te schrijven. Ziekenhuizen hebben zo veel verschillende systemen en zelfs ziekenhuizen onderling hebben andere systemen vergeleken met de ander.

Vind het apart dat operaties zo afhankelijk zijn van ICT systemen en dat als de back-up niet werkt, de mensen niet geopereerd kunnen worden.(Natuurlijk zijn er operaties die heel afhankelijk zijn van die systemen.) Hopelijk is hier verder niks mis gegaan, maar je zou denken dat Availability een belangrijk punt zal zijn als het aankomt op operaties die ook afhankelijk zijn op die afspraken. Misschien kunnen ze dan niet bij de dossiers van de patiënten die geopereerd moeten worden, maar dat is gewoon speculatie.

Yeah, vooral meer ICT in de zorg en het onderwijs

[Reactie gewijzigd door EMR77 op 11 januari 2019 18:55]

Nee, minder, minder, minder! Het idee dat een computersysteem een scan beter interpreteert dan een arts, dat moeten we niet willen met zijn allen.