Ict-storing patiëntenzorg Nederlandse Rijnstate-ziekenhuizen opgelost - update

Een mislukte systeemupdate heeft het elektronisch patiëntendossier van de Rijnstate-ziekenhuizen in de Nederlandse plaatsen Arnhem, Elst en Zevenaar getroffen. Het probleem is inmiddels opgelost.

"Alle problemen met het computersysteem zijn opgelost", laat Rijnstate weten in een bericht. "De storing is voorbij en dat betekent dat de patiëntenzorg weer opgestart kan worden. Alle patiënten die in het middagprogramma op de polikliniek een afspraak hebben, kunnen in het ziekenhuis terecht. Ook is het programma op de OK weer opgestart."

De storing werd maandagavond ontdekt na een reguliere update van een van de ict-systemen. Hoewel het probleem in eerste instantie verholpen leek, bleek dinsdagochtend dat de integratie tussen verschillende zorgmodules nog steeds niet functioneerde. Het systeem kon onder meer geen laboratoriumuitslagen en medicatiegegevens correct verwerken.

Als gevolg hiervan heeft het ziekenhuis dinsdagochtend alle poliklinische afspraken, geplande operaties, dagopnames en onderzoeken tot zeker 10.00 uur moeten annuleren. Voor patiënten die reeds waren opgenomen werd gewerkt met een noodprotocol om de continuïteit van zorg te waarborgen.

Update 12.50 uur: Artikel aangepast nadat Rijnstate liet weten dat alle problemen zijn opgelost.

Reacties (90)

[Manyuken]

En daarom dien je bij dit soort belangrijke systemen eigenlijk altijd minimaal Load-Balanced te draaien en elke update eerst te laten schaduwdraaien voordat je hem echt toepast...

[Reactie gewijzigd door Manyuken op 14 januari 2025 11:45]

[BertBertjes]

Fantastisch altijd dat Tweakers meteen zeggen hoe het beter kan / moet. Wie zegt jouw dat ze niet de update eerst uitvoerig hebben getest?

Waar gewerkt wordt vallen spaanders!

[Klaus_1250]

Waar gewerkt wordt vallen spaanders!

Er zijn plekken waar je dat niet kan veroorloven. Gezondheidszorg, ruimtevaart, militaire doeleinden. Fouten kunnen dan erg duur uitpakken. Dus er zijn tried en tested methoden om dit soort dingen te voorkomen. 100% voorkomen is onmogelijk, maar je kan vrij dichtbij komen.

[Keypunchie]

Volgens mij kan het ziekenhuis dit zich prima veroorloven. In de zin: ik denk niet dat het failliet gaat en ik denk niet dat de patientenzorg materieel in gevaar komt.

Ideaal is het verre van, maar precies omdat dit soort systemen niet 100% gegarandeerd kunnen worden, zijn er ook "offline" protocollen.

Dus niet te paniekerig.

[rdoorn]

Ziekenhuizen hebben op dit moment echt geen onbeperkt budget om naast een failover omgeving ook een volledige OTAP straat met alle koppelingen te kunnen draaien. Een ziekenhuis systeem is tegenwoordig wel iets complexer als een database-je met wat apparatuur.

[Quinto_nl]

Je hebt waarschijnlijk gelijk, hoewel ziekenhuizen ook echt wel zijn geprofessionaliseerd. Ik denk dat dat dat er in al wel in grote mate een OTAP straat beschikbaar is inc koppelingen, maar om alle scenario's te testen is echt bijna onmogelijk. Zelfs om alle applicaties in de infrastructuur op de juiste versies te hebben is al heel ingewikkeld. En dan neem je ook nog niet mee dat de load simuleren op een dergelijke infrastructuur ook technisch echt heel ingewikkeld (kostbaar) is.

[svdloop]

Ziekenhuizen zitten krap op de budgetten die niet direct onderdeel zijn van het zorgproces. Dat 'vinden we noodzakelijk' met z'n allen.
Het eco-systeem van systemen (want dat is het in een ziekenhuis) draait niet op één centrale server en vaak niet eens in één datacenter.
Updates van het EPD zijn sterk gestandaardiseerde processen, waarbij betrokken afdelingen elk verantwoordelijk zijn voor terugkoppeling over hun testresultaten.
Het gaat vaak over tientallen mensen die betrokken zijn bij update-windows (bij grote ziekenhuizen).

Een academisch ziekenhuis heeft meer dan 100 mensen in dienst die gericht zijn op IT.
Perifere ziekenhuizen ... significant minder.
Of alle ziekenhuizen een OTAP straat hebben? Het is een vereiste die Chipsoft bijvoorbeeld wel stelt. Zij doen alleen maar een implementatie als je aan de vereisten voldoet (inclusief hardware specificaties).
En dan nog, dan nog komt het voor dat je een omgeving hebt die niet up komt na een update.
Daarvoor zijn offline oplossingen in de vorm van nood-pc's. Daarop staat de informatie (protocollen) die noodzakelijk is om goede zorg te kunnen verlenen. Nadat de storing is opgelost móét de adminstratie bij worden gewerkt, maar zorg kan verleend worden.

[Robbierut4]

Volgens mij kan het ziekenhuis dit zich prima veroorloven. In de zin: ik denk niet dat het failliet gaat en ik denk niet dat de patientenzorg materieel in gevaar komt.

Dat is toch heel naief gedacht, er zijn de afgelopen jaren al meerdere ziekenhuizen failliet gegaan. Denk bijvoorbeeld aan het Slotervaartziekenhuis en de IJsselmeerziekenhuizen.

[Keypunchie]

Die is niet failliet gegaan door een ICT-probleem. Daar ligt een heel ander issue aan ten grondslag. Namelijk hoe we zorg bekostigen in Nederland.

[BertBertjes]

Je zegt het zelf al 100% voorkomen is onmogelijk, en wie zegt jouw dat ze niet uitvoerig dat hele proces getest hebben? Vanaf de zijlijn roepen hoe het allemaal beter kan en moet is altijd heel makkelijk scoren.

Vaak is er een kosten aspect mee gemoeid, want een complete schaduw omgeving is vaak in (zorg)instellingen vaak veel te duur en overkill.

[thunder7]

In een ziekenhuislab, met apparatuur van tonnen, is er echt geen budget om die apparatuur in duplo neer te zetten om zo af en toe een update te testen. Tegelijkertijd kun je de apparatuur van de productieomgeving ook niet heel gemakkelijk even aan de testomgeving hangen, want de productie moet wel doorgaan.

En voor het volledig testen van een test-omgeving van een communicatieserver als Cloverleaf geldt dat ook, die is er wel, maar niet alle bronnen zijn in test beschikbaar.

[QuintMidas]

Het gaat voor zover ik heb begrepen in deze case niet om apparatuur, maar IT-systemen waarin gegevens als patiënten-, medicatie- en zorgregistratiedata worden vastgelegd.

[massareal]

...die apparaten moeten het toch ook ergens naar toe schrijven.
Ik heb ook ruim 25 in de IT voor een groot ziekenhuis gewerkt en ik kan je vertellen dat het geen katte pis is met al die speciale en exotische apparatuur.
Een hoop van het hele specialistische kan gewoon niet getest worden, vaak draaien die in aparte virtuele omgevingen en de koppelingen zijn dan geschreven code, door 1 specialist (die dan vaak er niet meer werkt).

...en ander probleem is dat testen gewoon geld kost en als er niet genoeg budgeteer wordt, kan je ook maar beperkt testen (los dat je nooit 100% kan testen)

[FrankHe]

Fouten zijn niet te voorkomen, hoe erg je ook je best doet door alles vooraf uitgebreid te testen. Het kan van alles wezen, die dingen kunnen nu eenmaal gebeuren.

[Frame164]

Fouten zijn te voorkomen door niets te doen behalve commentaar geven op anderen die wel wat doen. Zoals de betweter reageerder pas op deze en andere sites….

[FrankHe]

Ik begrijp niet helemaal wat je schrijft maar ik neem aan dat je bedoelt dat er in het leven nu eenmaal dingen gebeuren dan dat we daar niet te veel over moeten zeuren.

[kabelmannetje]

Graag hoor ik precies in detail van je hoe deze tests zijn uitgevoerd. En hoe deze toch door de tests geslipt zijn wat tot de downtime leidde.

[Argantonis]

Gezondheidszorg hoort in de praktijk totaal niet in dat rijtje thuis. Daarvoor kost het gewoon te weinig als het mis gaat en is het niet belangrijk genoeg. En dan bedoel ik niet in woorden, want iedereen gaat zeggen dat het belangrijk is, maar in daden. Nederland heeft al dik 20 jaar centrum-rechts tot rechtse kabinetten gehad en de zorg alleen maar verder is uitgekleed. Uiteindelijk heeft de bevolking dit gekozen.

[sympa]

De zorg is behoorlijk gemechaniseerd. Maar spreek eens een (huis)arts, die zal je zeggen dat er tegenwoordig zoveel meer kan (en gebeurt!) dan vroeger.
Zoals je tegenwoordig zomaar even een CT of MRI krijgt. Terwijl dat vroeger iets was van een enkel ziekenhuis.
En zoals je daar weer voor eigenlijk amper wat had qua medicijnen. En wat er was had akelige bijwerkingen.

[Zjemm]

Helemaal mee eens. Iedereen heeft altijd meteen zn zegje klaar (ook ik wel eens).
Maar je mag er toch van uitgaan dat de mensen daar ook gewoon goed bezig (willen) zijn. En natuurlijk zal dat niet voor 100% van de gevallen gelden.

Dus als je vind dat het beter moet, bied je hulp aan zou ik zeggen

[TheDudez]

Dat niet alleen vaak zijn dit soort oplossing te duur.

[CAPSLOCK2000]

Fantastisch altijd dat Tweakers meteen zeggen hoe het beter kan / moet. Wie zegt jouw dat ze niet de update eerst uitvoerig hebben getest?

Waar gewerkt wordt vallen spaanders!

Maar het kan en moet ook beter.

Dat overal waar gewerkt wordt spaanders vallen moet accepteren je maar je moet er ook van leren. Niks in de wereld is perfect en vrijwel iedere complexe beslissing is een compromis.

Het klopt dat het vanaf de wal makkelijk is om maar wat te roepen en het werk van een ander af te branden, maar kritiek leveren hoort bij het leerproces. Zolang dit soort commentaar technisch van aard is (en niet tegen de personen gericht) zie ik het vooral als behulpzame suggestie aan andere Tweakers, niet als verwijt.

[Keypunchie]

Niet per se oneens, maar het zijn niet meer de jaren '00.

Servers draaien niet meer in het rack in de bezemkast en het beheer ligt niet meer bij een "webmaster".
Om anno 2025 te gaan roepen "je hEbT een BaCkUp nOdIg!" voegt niet heel veel toe.

Helaas lijkt dat wel een beetje het niveau.

Maar de praktijk is tegenwoordig vele malen complexer. Vroeg liep ik als beheerder "even naar zaal", om de server te rebooten en we gingen weer verder. Voor een deployment kreeg ik een file aangeleverd en die zette ik op de juiste plaats buiten kantooruren. Als ik de instellingen van een applicatie aanpaste, maakte ik even kopietje "config.old".

Tegenwoordig wordt er heel veel DevOps gewerkt. De developers en/of de business kiezen zelf wanneer ze deployen, door middel van CI/CD.

Hun applicaties zijn gevirtualiseerd en draaien als container op een containerplatform. Dat platform is een cluster van "hardware" dat zelf ook weer een abstractie is, want door middel van een virtualisatielaag, komt dat terecht op "compute" en "storage", die zelf ook alleen maar een logische definitie zijn. Met een beetje pech of geluk wordt er ook nog eens dynamisch op- en afgeschaald.

De middleware is vaak ook alweer alleen maar een logische toewijzing. Een database bestaat als virtuele database op een cluster. De storage van die database is net als die van de compute hardware, ook weer een een abstractie van onderliggende disken.

Het netwerk dat de toegang geeft? Een abstractie. Software-defined networking met virtuele firewalls en virtuele loadbalancers.

Het grote voordeel van al deze abstracties op abstracties is dat deze systemen heel flexibel en redundant zijn. Ik ken (cloud) softwaretoepassingen waarbij je rustig een half (of zelfs heel!) datacenter van de stroom kunt trekken en hoogstens merkt de eindgebruiker dat zijn webpagina in 400 ipv. 200ms inlaadt. Alle transacties vlekkeloos en soepel doorgeschakeld. Een deployment, het vervangen van hardware, of uppgrade van de database? Dit kan allemaal gewoon onder kantoortijd, niemand merkt er iets van.

Niet dat mensen inloggen in deze systemen. Dat gebeurt weer allemaal via versiebeheer en geautomatiseerde deployments. Monitoring is een abstractie, waarbij metrics naar een centrale database worden gestuurd, waar je tresholds kan instellen.

Het nadeel: Als er iets aan het radarwerk zelf niet werkt, dan is door de abstracties het lastig om het bos nog te zien. Je hebt een storage-team, een netwerk-team, een applicatie-team, een tooling-team, een database-team, een security-team, etc. Ga er maar aan staan.

En hoe dat op te lossen, is voor elke organisatie weer anders, omdat de systemen echt supercomplex zijn geworden. Dan is de mededeling "OTAP straat en loadbalancer" toch echt te weinig. Om daar zinnig advies voor te kunnen geven, zul je eerst de organisatie moeten leren kennen en hun 'maturity'.

[ZinloosGeweldig]

Nu zijn de zaken die vanaf de wal geroepen worden zodra er ergens een storing is meestal wel het meest laag hangende fruit.

Terwijl de oorzaak van de verstoring meestal niet zit in het negeren van dat laaghangende fruit, maar de situatie een stuk complexer is.

Het is een beetje alsof onder elk bericht over een verkeersongeluk verteld wordt dat als je aan het verkeer deelneemt, het belangrijk is dat je remmen goed werken.

[Reactie gewijzigd door ZinloosGeweldig op 14 januari 2025 16:16]

[Caelestis]

Waar het meestal mis gaat is met een degelijke FMEA analyze.
Vaak ligt dit stuk bij een enkele afdeling en wordt er weinig aandacht besteed aan de risico's.
"We zien wel wat er gebeurt" is de oplossing.
En als je dan niet van tevoren hebt bedacht hoe je het terug draait, moet een nieuws site hierover rapporteren.
Als dit in het nieuws komt ben je veel te laat en is bewijs dat er niet correct getest wordt.

[david-v]

Als dit in het nieuws komt ben je veel te laat en is bewijs dat er niet correct getest wordt.

Jij hebt vaak een OS/DB (security) patch op productie getest? Want je kan je een ongeluk testen op de OTA omgeving bij een dergelijk patch, totdat je hetzelfde in productie doet en dan toch een probleem krijgt. 99% van de keren gaat het goed, in dit geval helaas niet. Jouw conclusie is denk ik te voorbarig.

[Caelestis]

Je geeft precies het probleem aan.
99% van de tijd gaat het goed.
Waarom zou je dan elke keer een FMEA analyze moeten doen?
Het is irritant en wordt zo veel mogelijk vermeden.
Als dit geen medische sector zou zijn is dat 1% geen einde van de wereld.
In dit geval zullen de patiënten er anders over denken.

[david-v]

De FMEA is een papieren exercitie waar je ook niet alles mee kan dekken. Bovendien doen wij dit zelf ook vaak een toch gaat het soms mis. Het in onderhoud zetten van de it systemen zou dan een van acties kunnen zijn om de systemen te herstellen. Shit happens, met en zonder FMEA

[Caelestis]

Oh jazeker het gaat ook fout met een FMEA maar als je in de basis niet eens een methode hebt toegevoegd om je patch terug te draaien, dan is dit exact het punt waarbij het hele verhaal mis ging.
Hoe goed iedereen ook is, shit happens. Wees erop voorbereid en het achtervolgt je niet.

[Frame164]

Dus jij claimt dat jij alle fouten kunt voorkomen. En daar durf je je handen voor in het vuur te steken? Durf je een weddenschap aan te gaan waar je al jouw bezittingen in zet als je toch een keer een probleem hebt?

[Caelestis]

Voorkomen? Tuurlijk niet, maar daar zijn de concepten zoals een FMEA voor ontwikkeld. Elke mens maakt fouten.
Het gaat erom dat je op zijn allerminst zorgt dat deze niet onherstelbaar zijn en je aan een journalist moet uitleggen waarom het patiënten zorg stil komt te liggen.

Het is ronduit beschamend dat dit in de medische sector gebeurt.
Er is geen excuus.

Weddenschap voor geen fouten ga ik niet aan.
Een weddenschap voor het adequaat kunnen verhelpen van het probleem voordat de media er wind van krijgt. 100% Wat leg jij in?

[Keypunchie]

Wie zegt dat niet van te voren is nagedacht? Vaak genoeg meegemaakt dat een rollback die in test werkte, op PROD even anders uitpakte.

Wel eens gehad dat, na een noodzakelijke rollback, de primaire database het plots nodig vond om een volledige integriteitscheck uit te voeren. Had ‘ie in OTA niet gedaan. Op zich niet raar zo’n check, maar betekende wel dat de hele database op slot zat, tot de check klaar was.

Ook niet zo’n issue, behalve dat er een paar miljard transacties in zaten, dus er kon koffie gezet gaan worden, want het geintje zou geschat tussen de 8 en 16 uur gaan duren.

Leverancier gebeld van het systeem. Zegt die doodleuk: ja, is een bekende bug, soms triggert dat zomaar, we weten de oorzaak nog niet echt, dus kunnen jullie de logs opsturen als het klaar is?

Tsja.

[Caelestis]

Zou leuk zijn als een ziekenhuis tussen de 8 en de 16 uur geen normale dienst kan leveren.
Het is maar hoe belangrijk je de risico's inschat.
Bij ons is alles dubbel uitgevoerd dus we kunnen heen en weer switchen wanneer nodig.
De oplossingen zijn rijkelijk beschikbaar. Het is niks nieuws, maar hoe complexer het probleem, hoe duurder het wordt.

[jaenster]

Daarom hebben ze ook tijd om op tweakers te zitten de hele dag, want al hun meuk werkt en draait en hebben geen issues

[Paul]

En dat hebben ze ongetwijfeld gedaan. Ik ben alleen bekend met de procedure bij Epic, niet bij Chipsoft, maar ik kan me niet indenken dat er zoveel verschil in zit. Ziekenhuizen stoppen behoorlijk veel geld in het voorkomen van het moeten nemen van dit soort maatregelen, en er wordt vooraf echt wel goed getest.

Probleem is dat je productieomgeving *altijd* anders is dan je acceptatie-omgeving. Hoe goed je ook je best doet, er zijn altijd verschillen. En zeker aangezien dit de integratie met andere systemen betreft is het landschap waar je het over hebt nog veel groter, en zijn er nog meer verschillen. Een vinkje wat anders staat, een t/a-server van een van die koppelingen die op een nieuwere versie draait want dat pakket zit halverwege hun eigen upgrade, etc. etc. etc.

En je kunt niet de helft van je productieomgeving upgraden en de andere helft niet, want er is maar één database, en de oude versie van de software kan niet met de nieuwe database, en de nieuwe versie van de software kan niet met de oude database. Nu ja, een oudere client (op je PC) kan vaak wel met een nieuwere database, maar voor de koppelingenservers geldt dat niet.

[Reactie gewijzigd door Paul op 14 januari 2025 11:15]

[Olaf van der Spek]

En je kunt niet de helft van je productieomgeving upgraden en de andere helft niet, want er is maar één database, en de oude versie van de software kan niet met de nieuwe database, en de nieuwe versie van de software kan niet met de oude database.

Klinkt als een recept voor problemen..

Als de upgrade niet werkt zou een snelle rollback wel handig zijn.

[Reactie gewijzigd door Olaf van der Spek op 14 januari 2025 11:33]

[DinX]

Een simpele rollback is vaak niet mogelijk in een ziekenhuis omgeving.

De applicatieve omgeving binnen het gemiddelde ziekenhuis is een kluwen ven ketens en geautomatiseerde systemen. Je kan vaak niet even gewoon een rollback doen of een backup terugdraaien.

Denk daarbij aan zaken als patientbewegingen, een HL7 bericht dat al door 10 verschillende Mirth kanalen gepasseerd is en daar overal al diverse acties gestart heeft,...
Op een uur tijd kan een patient opgenomen zijn op de spoed, een RX gedaan hebben, medicatie voorgeschreven hebben via het EPD.
Dat voorschrift is op zijn beurt doorgestuurd naar het systeem van de medicatiekasten, bij het uitnemen daar is die medicatie gescanned en de stock aangepast, bij het toedienen wordt het bandje van de patient gescanned en de medicatie. Deze toediening is automatisch verwerkt en toegevoegd in het EPD,....

Als de stock in de medicatiekast te laag is geworden wordt dit automatisch doorgegeven aan het systeem van de medicatiekasten. Deze triggeren op hun beurt iets in het ERP systeem wat zorgt dat logistiek 2 nieuwe doosjes komt brengen bij de volgende ronde. Als het iets is wat via de apotheek moet komen wordt daar eerst nog een trigger gestuurd die de robot in de apotheek de medicatie uit de rekken laat halen en klaar zet,...

Dus door een simpele actie als het voorschrijven van medicatie worden al snel zeker 10 verschillende processen opgestart, op verschillende servers van verschillende leveranciers,...
Je kan niet even de boel terugdraaien bij dergelijke systemen.

Dan spreek ik hier nog enkel over de flows binnen hetzelfde ziekenhuis. Vaak heb je ook collega en/of partnerziekenhuizen die daarom niet hetzelfde EPD systeem gebruiken. Misschien wordt ergens in die keten van transacties een HL7 bericht doorgestuurd naar 1 van de partner ziekenhuizen, dat misschien een ander EPD systeem heeft. Ook daar kan dat weer door verschillende systemen gepasseerd zijn, verschillende acties getriggerd hebben,...

[Reactie gewijzigd door DinX op 14 januari 2025 15:31]

[jip_86]

Precies, het word ongetwijfeld getest. Maar het OTA deel zal niet over (alle) koppelingen beschikken die productie wel bevat. Dat ze zeggen dat ze oa geen labuitslagen kunnen ophalen klinkt alsof het juist in dat deel ergens mis is gegaan.

[DinX]

Als het heel het systeem van het EPD is zal het meer zijn dan dat alleen.
Stel de web services van het EPD in het ziekenhuis waar ik werk liggen uit, dan kan je zowat 3/4 van het zorgproces met pen en papier gaan doen.

In het EPD zit heel je planning, heel je patientendossier, de voedingsadministratie, het bekijken van radiologiebeelden ( al kan dat ook via andere wegen), de OK planning, het zorgproces zelf (doe bij patient x om 11u00 dit, om 11u45 dat,...),...

Als dat langer dan een bepaalde tijd uit ligt gaat de boel inderdaad dicht en worden verschillende noodprocedures gestart.

[Ludwig005]

Low balanced?

[njitter]

ik denk dat hier load-balanced moet staan. Maar ook dat heeft weinig nut als beide systemen dezelfde foute update krijgt.

[Frituurman]

Mwah.. je gaat natuurlijk eerst een check doen op de eerste en als dat niet werkt, dan rol je terug. Dan is eigenlijk vrij standaard bij dit soort omvangrijke uitrollen. Maar mogelijk is daar niet voor gekozen, omdat de update uitvoerig is getest. Wellicht was de testomgeving echter niet helemaal productielike. Of is er tijdens de installatie van de update een menselijke fout gemaakt die lastig terug te draaien is. Allemaal gissen. Je kunt in elk geval nooit 100% testen en alles uitsluiten voor livegang. Soms gaat het 'gewoon' fout.

[Manyuken]

Dat klopt, maar het gaat wel om risicovermindering. Wellicht was High-Availability wellicht een betere optie geweest zodat je altijd een machine hebt die het over kan nemen weer. Maar het is inderdaad moeilijk te zeggen aan de hand van de tekst hier wat ze precies allemaal hebben gedaan, of juist niet hebben gedaan.

Mijn punt was meer dat je met grote wijzigingen op belangrijke systemen eigenlijk nooit zonder dergelijke opstellingen en backup-oplossingen kan...

[Frituurman]

Dat ben ik roerend met je eens. Bij ons moet voor elke change, hoe klein ook, een tested and proven rollback scenario aanwezig zijn. Je kunt risico's niet tot nul terugbrengen, maar je kunt ze wel mitigeren.

[Frame164]

Ook HA is geen garantie dat iets 100% goed gaat. HA is eigenlijk ook niet bedoeld om migraties te faciliteren maar is bedoeld om SPOFs te verminderen of te elimineren.

[TheVivaldi]

Dat ook, en dan nog kan het in de praktijk misgaan. Dat iets bij schaduwdraaien goed draait, wil niet zeggen dat het in de praktijk ook goed draait. Het is hooguit een indicatie dat het zeer waarschijnlijk goed zal gaan, maar geen keiharde garantie.

[Tomolone]

Ik gok dat @Manyuken Load Balanced bedoelt, en dat beide systemen tegelijk draaien om te kijken of alle functionaliteiten correct draaien. A-B test voor je naar B omschakelt zeg maar.

[nelizmastr]

Dat is geen loadbalancing maar onderdeel van OTAP.

[satya]

Hoeft niet, in een microservice architectuur kun je er een bijgewerkte container naast zetten die dezelfde acties verwerkt en langzaam alle bewerkingen overneemt.

[Argantonis]

Zijn punt was dat het dan niet om load balancing gaat maar om hoe je iets live zet. Dat de functionaliteit deels overlapt betekent niet dat het doel hetzelfde was.

[Manyuken]

Sorry autocorrect... moest inderdaad load-balanced zijn...

[gaskabouter]

Ik zou direct solliciteren.

In mijn ziekenhuis draaien meer dan 300 programma's direct gerelateerd aan patiëntenzorg. Het is een illusie te denken dat problemen met koppelingen na updates altijd voorkomen kunnen worden.

Meestal onhandig soms onveilig en dat is dit het enige juiste besluit.

[Reactie gewijzigd door gaskabouter op 14 januari 2025 11:14]

[MarcieMars]

Inderdaad vrijwel onmogelijk om je acceptatie omgeving hetzelfde te hebben als je productie in zo'n situatie. Er wordt gekoppeld met systemen die locaal staan, en in diverse clouds. Sommige zaken worden "as a service" afgenomen. Met stubs/mocks kun je wel wat maar blijft beperkt. Dan heb je ook nog eventueel issues met de data, een patient die in productie in systeem A en B bestaat kan in op acceptie alleen in systeem A en C bestaan.

Daar bovenop nog allerlei regulering bij vwb patientdata, je mag niet zomaar even een "snapshot" trekken van productiedata voor acceptatie. Je moet dan de data gaan anonimiseren.

[schmm]

een OTAP straat. Of op zijn minst een TP straat. (TEST > Productie)

Load-balancing schiet niet heel veel op in zo'n geval aangezien alle systemen gelijktijdig geupdate worden die in het cluster zitten.

[mutsje]

Je bedoelt denk ik op zijn minst een AP straat acceptatie en productie. Een test omgeving is meestal voor software ontwikkelaars. Deze heb je niet veel in ziekenhuizen. En anders hebben ze hun eigen testomgeving. Wij draaien hier een TAP omgeving maar puur om testen uit te kunnen voeren omdat dit not done is op een acceptatieomgeving. En nog gaan er soms zaken onverwacht niet goed hoe goed het ook ingericht en geaccepteerd is.

Als iemand over load-ballancing begint dan moet die eerst maar eens in de keuken van ziekenhuizen kijken hoe de IT daar ingericht is. Sure clusters en load-ballancers genoeg maar dat heeft weinig met acceptatie en productieomgeving(en) te maken.

[mjtdevries]

De O omgeving is voor software onwikkelaars.
De T omgeving is voor alle andere tests, zodat je alleen dingen in je A omgeving doorvoert die al goed getest zijn. Je wilt je A omgeving zo min mogelijk aanraken zodat die gelijk blijft aan je productie omgeving.

[mutsje]

Ja ok point taken O hebben we niet dan en de T gebruiken we zelf om alles wat nieuw is eerst te testen. En inderdaad de A en P blijf je vanaf. Anders kan je regressie testen gaan doen..

[ZinloosGeweldig]

Als je je eigen software ontwikkelt en host wil je een volledige OTAP straat ja.

Maar als je gebruik maakt van (on premise) software van een leverancier, dan leven O en T in principe bij de ontwikkelaar (daar wordt de software ontwikkeld en getest voordat die uitgeleverd wordt).

Vervolgens draait bij de afnemer A en P om acceptatietesten op de uitgeleverde update uit te voeren voor deze in de P omgeving geïnstalleerd wordt.

[Reactie gewijzigd door ZinloosGeweldig op 14 januari 2025 16:09]

[david-v]

Makkelijker gezegd dan gedaan . Een realtime productie schaduw omgeving is een uitdaging en is ook prijzig. Kosten-baten analyse is dan belangrijker dan uptimes van 99.99(9)%.

[satya]

Niet in een microservices architectuur, dan kun je containers dubbel laten draaien en het verkeer beheerst omleiden naar de bijgewerkte container.

[david-v]

Microservices is (vaak) maar een klein deel van de keten. Je hebt geen micro databases, micro load balancers, micro firewalls enz.

[satya]

Bij het updaten van software allemaal geen issue.

[david-v]

Bij het updaten van de loadbalancer, patches op de database, updates op de firewall....zoals gezegd, je gaat er nu van uit dat het om een software update ging van een service. Maar in de titel staat dat het om een systeemupdate gaat, een reguliere update. Denk aan OS patches, security patches enz. Dat los je niet op met een microservice architectuur. Microservice is maar een deel van het geheel zoals ik al eerder zei.

[wolfstein89]

Want u werkt met deze ziekenhuissystemen? Ik snap dat je dat graag wil, maar in de praktijk blijkt dit niet altijd mogelijk.

[beerse]

Als je load-balanced bedoeld, dan zie de overige reacties.
Als je het onderscheid probeert te maken tussen transactie-log-shipping (high/snel) of journal-logshipping (low/vertraagd) zoals dat bij sommige database systemen heet: Dat maakt niet uit. Als er een issue in de software is, dan is er een issue in de software. Bij een update met een uitdaging en een meervoudig uitgevoerd systeem is er altijd een uitdaging.

En zeker hier waarbij het een aantal uur heeft geduurd voordat het werd ontdekt, dan wil je niet weten wat waar al is fout gegaan. Een ziekenhuis draait 24 uur per dag, 7 dagen per week. De patiënt administratie dus ook.

Vooral succes aan het verplegend en verzorgend personeel dat nu de patiënten dossiers handmatig moet bijhouden en dat later allemaal moet verwerken.

[Jelle656]

Ah, daar hebben we weer een typische Tweakers reactie. De klok horen luiden maar geen idee waar de klepel hangt. Tenzij je toevallig bij het Rijnstate werkt kun je met geen zinnig woord zeggen wat hier wel en niet is gebeurt. Shit happens sometimes, 999x gaat het goed (waar we niets over horen) en soms gaat het een keer fout ondanks alle procedures, testen, draaiboeken etc. Geloof me, ziekenhuizen (het Rijnstate ook) gaan in de basis heel zorgvuldig om met wijzigingen die raakvlakken hebben met het EPD of alles wat daaraan vast hangt.

Gegevensuitwisseling tussen zorgsystemen gebeurt veelal op basis van de HL7 standaard m.b.v. een integratieplatform als Cloverleaf. Op basis van bovenstaande berichtgeving klinkt het alsof daar iets is omgevallen waardoor gegevens niet meer uitgewisseld kunnen worden. Maargoed, het blijft gissen. Hopelijk is de oorzaak snel duidelijk en kan het snel opgelost worden, heel vervelend dit voor alle betrokkenen.

[Reactie gewijzigd door Jelle656 op 14 januari 2025 11:45]

[Abom]

Wat heeft load-balancing hiermee te maken? OTAP is de methode die je gebruikt om mogelijke issues te identificeren voordat je dergelijke wijzigingen live zet. Maar dan nog hebben wij waarschijnlijk onvoldoende informatie om ook maar iets zinnigs over de oorzaak.

[Djerro123]

En daarom dien je bij dit soort belangrijke systemen eigenlijk altijd minimaal Load-Balanced te draaien en elke update eerst te laten schaduwdraaien voordat je hem echt toepast...

Ik heb in de missie kritische IT gewerkt (je weet wel, waar het echt niet uit mag, zoals ziekenhuizen). Als ik een euro kreeg voor elke “full stacker” die wel even zou uitleggen hoe je HA bereikt, dan kom ik stoppen met werken.

Leg jij mij even uit hoe je je database loadbalanced. En voordat je komt met “ja als je je services goed heb opgezet, dan kan zowel A als B omgaan met het nieuwe schema”; wat als je je schema niet backwardscompatible kan maken?

Een A B setup werkt leuk voor je websiteje (“oh noo er is geen omzet als de webwinkel het niet doet, ik doe super belangrijk werk”) maar een EPD is geen simpele web applicatie.

Waar gewerkt wordt vallen spaanders; en ook hier werken professionals die zich in het zweet werken. Je mag ook een beetje compassie tonen voor degenen die hier als een dolle bezig zijn de boel weer op te starten in een omgeving met 1000 bewegende delen.

Schaduwdraaien… echt shaking my head bij het lezen van deze eerste reactie.

[Arfman]

Oh ok, bedankt voor dit inzicht! Ik weet zeker dat het ziekenhuis nu hun procedures gaat aanpassen naar aanleiding van deze inzichtvolle post.

[EnigmaNL]

Bel ze even op om je hulp aan te bieden. Met jouw kennis zijn ze binnen een uurtje weer up and running!

[Frame164]

En met die kennis kan hij toch gauw 250 euro per uur vragen. Iedere seconde dat hij op tweakers reageert kost m een vermogen.

[EnigmaNL]

Nou inderdaad. Zo iemand kan enorm rijk worden, maar kiest ervoor om te posten op Tweakers.

[PetervdM]

als het om het HIS systeem gaat, is schaduwdraaien maar beperkt mogelijk, want je kunt niet de koppelingen testen met de overige ziekenhuis systemen, en dat lijkt hier het probleem te zijn.
het is zeer kostbaar alles dubbel uit te voeren, daar hebben de ziekenhuizen gewoon het geld niet voor, of heb je liever dat je zorgpremie nog enkele tientjes per maand hoger wordt?

[wlmpie]

Of je zorgt voor een plan B zonder ICT. Veel minder efficient en lekker ouderwets natuurlijk maar dan kun je door met je missie-kritieke dienstverlening in geval van een cyber aanval of computerstoring. Alle ICT driedubbel uitvoeren kost vooral veel geld en en conform de wet van Murphy gaat het soms uiteindelijk toch nog mis.

[Frame164]

Nee, dat werkt niet want je hebt geen mensen om dat uit te voeren. Stel dat je alles al in papieren dossiers hebt, dan is de tijd die het kost om een dossier uit het archief te halen al voldoende om de werkzaamheden in een ziekenhuis binnen een half uur vast te laten lopen.

[metalmania_666]

Ik heb in de financiële wereld gewerkt. Daar wordt alles zeer uitvoerig getest via OTAP en load-balancing is daar ook onderdeel van.
En toch gaat het af en toe fout. Je kunt nu eenmaal niet iets 100% krijgen.

De beste stuurlui staan aan wal

[Randfiguur]

Ben geen expert, maar dit klinkt vreemd:

"Een mislukte systeemupdate heeft het elektronisch patiëntendossier ... getroffen."

Het lijkt mij waarschijnlijk dat er met de patiëntendossiers zelf niets mis is, maar wel met het systeem waarmee die bewerkt en gemanaged worden?

[SgtElPotato]

Ik neem aan dat dit een versimpelde versie is om naar buiten te brengen. Het onderliggende probleem zal vast een stuk complexer zijn..

[phoenix2149]

Wij hadden voor dit soort zaken een rampenplan die zorg draagde dat op zijn minst spoed altijd gedaan kon worden ook zonder netwerk. Gewoon klassiek papier en mappen.

[Appeltjeeitje]

Voor de patiënten erg vervelend. Zelf meegemaakt hoe onrustig je kan zijn voor (de uitslag van) belangrijke onderzoeken. Wordt die termijn van angst helaas nog langer.

[rdfeij]

Een beetje begrip mag wel, het hele ziekenhuis staat in paniekstand. Dit soort grote zaken gaan over vele schijven en terwijl jij onderweg bent worden er mogelijk nog meer storingen gevonden en dus afdelingen gesloten. Voordat iedereen gebeld is zit je daar mogelijk dus al.

Ze zullen binnenkort vermoedelijk wel op zoek zijn naar een nieuwe changemanager

[Sabes]

Hoezo direct op zoek naar een nieuwe changemanager? Het lijkt me logischer dat de changemanager samen met problem en incidentmanager nu eerst gaat kijken hoe 1) de change weer zo te krijgen dat deze werkt (ofwel rollback, ofwel fixen) en dan evalueren voor de toekomst.

Of heb jij er weet van dat changes aan de lopende band daar niet goed gaan.

[rdfeij]

daar stond niet voor niets een smiley achter.... Ik snap ook wel dat dat niet zo simpel gaat.

[Frame164]

Je hoeft hier geen vrij voor te nemen. Je krijgt vrij voor medische zaken.

[Shaker74]

Was voor mijn minderjarige dochter.