Vlaamse ziekenhuizen stellen operaties uit door oververhitte server in Parijs

Twee Vlaamse ziekenhuizen melden problemen door oververhitting van een server in Parijs. Het Universitair Ziekenhuis Antwerpen stelt bepaalde zorg uit en het Gentse AZ Sint-Lucas voert helemaal geen operaties uit. Op de getroffen server staat het elektronisch patiëntendossier.

Volgens het UZA is de koeling inmiddels hersteld en start het ziekenhuis de systemen opnieuw op. "We hopen in de komende uren normaal operationeel te zijn." Spoedgevallen en dringende ingrepen gaan hier wel door, maar raadplegingen, geplande opnames en ingrepen worden uitgesteld of lopen vertraging op.

Het Gentse ziekenhuis leidt spoedgevallen om naar andere ziekenhuizen. Ook hier vinden geplande ingrepen op een later moment plaats. Bij beide ziekenhuizen gaat een deel van de zorg nog wel door, zoals consultaties, chemotherapie, nierdialyse en PET-CT-scans. De ziekenhuizen zeggen verder patiënten persoonlijk te informeren over de storing.

Update, vrijdag 26 juni, 08.50 uur – De elektronische patiëntendossiers zijn bij het UZA inmiddels weer beschikbaar. Geplande afspraken gaan weer door. Het AZ Sint Lucas zegt nog steeds problemen te hebben.

Bron: Jason Marz/Moment/Getty Images (Afbeelding ter illustratie)

Reacties (128)

[sstad]

Dit is dus letterlijk een server die oververhit is geraakt bij de externe partij in Parijs die het EPD beheert voor deze ziekenhuizen, niet "de koeling van een datacenter" of iets dergelijks. Dat maakt het wat mij betreft nog wranger.

Tegenwoordig zou dit gewoon niet meer mogen kunnen. High availability voor een systeem dat letterlijk operaties en patiëntenzorg stillegt is geen luxe, dat is basishygiëne. En toch kom ik in de praktijk nog steeds omgevingen tegen waar één kritische server zonder enige vorm van redundantie draait. Ik ben zelfs ooit nog een server tegengekomen die op Windows 3.11 draaide. Geen grap.

[Reactie gewijzigd door sstad op 25 juni 2026 10:35]

[coolkil]

Echte ha over een multi site architectuur is gewoon heel erg lastig.

is altijd makkelijk om daar van achter je toetsenbordje wat van te vinden.

Uiteraard zijn er technische oplossingen denk aan Kubernetes of in de hypervisor layer live migration. Echter… dan komt er een license of bedrijfs politiek discussie. (Netwerk en opslag even buiten beschouwing gelaten)

Fictieve voorbeeld situatie: leverancier zegt Als je product EPD op vmware zet betaal je voor alle 400 cores in je cluster ook al gebruik je er maar 2. Dan betaal je voor 1 database dus een enorme klap geld wat niet economisch haalbaar is

[Reactie gewijzigd door coolkil op 25 juni 2026 11:33]

[mjtdevries]

Een EPD is echt supersimpel HA te maken over een multi site architectuur.

HA kan wel lastig zijn met oplossingen die realtime moeten kunnen werken. Oplossingen waar het kleinste beetje extra latency een probleem is. Maar of je dossier in 1 seconde of 1,2 seconde word opgehaald is echt niet van belang.

Wat meer waarschijnlijk is, is dat er op papier wel een nette HA oplossnig is, maar dat er in de praktijk toch iets mis is gegaan wat niet voorzien was.

Iets waar je vaak tegenaan loopt is dat servers wel redundant zijn en een automatische failover zouden moeten doen. Maar dat je op de een of andere manier in een situatie komt waar die automatische failover niet gebeurt. Vaak is dan handmatig die failover triggeren voldoende om de oplossing weer in de lucht te krijgen.

[dmantione]

Dat komt bijzonder vaak voor: HA is niet zo moeilijk op te zetten, maar het is bijzonder complex in de analyse wat er allemaal mis kan gaan en wanneer failover plaats moet vinden. Een server die vastloopt is feitelijk de makkelijkste situatie, maar tussen een werkende server en een vastgelopen server zit een enorm grijs gebied.

Het falen van een server kan ook schijn zijn, de server kan het gewoon druk hebben. En echt goed HA-systeem is daarmee best wel complex om tegen alles wat er kan gebeuren te blijven werken.

Ik zal je zeggen, mijn werkgever installeert HPC-clusters, en bij een groot cluster met veel gebruikers ga je natuurlijk dingen HA maken, zodat uitval van een systeem niet opgemerkt wordt. De praktijk laat helaas maar al te vaak zien dat niet HA-systemen de korste downtijden hebben, gewoon omdat ze veel eenvoudiger zijn.

Het is volledig onacceptabel om in een ziekenhuisomgeving geen HA te hebben, maar het is wel vaak de ijzeren wet, dat de minst complexe systemen de meest betrouwbare systemen zijn, die in dit soort situaties toeslaat.

[hakariki]

Hear, hear! Het verschil in inzicht tussen "HA is simpel" en "HA is complex" komt mijn inziens altijd vanuit het verschil in complexiteit van de systemen die HA draaien. Een simpel systeem is simpel HA te maken, eem complex systeem is dat echter niet. Dat is voor mij de regel. En dat zie je terug in de reacties. Mensen die roepen dat HA simpel is hebben nog nooit gewerkt met echt complexe systemen.

[Reactie gewijzigd door hakariki op 25 juni 2026 13:25]

[mjtdevries]

Je hebt helemaal gelijk. KISS vs HA

Een server die crashed is in een HA oplossing geen probleem. Maar het gaat bv mis als een server extreem traag word maar wel reageert op een heartbeat. Geen failover omdat de heartbeat er gewoon is, maar wel klagende gebruikers.

[SunnieNL]

Hoe het aan de achterkant gedaan moet worden is niet aan het ziekenhuis op het moment dat jij een SaaS dienst afneemt of een managed service.

Wat wel voor rekening is voor het ziekenhuis en zeker in belgie is de NIS2 en de bijbehorende risico analyse en continuiteit. Het is vrij slecht van het ziekenhuis als zij niet een uptime of een te lage uptime hebben afgesproken voor de EPD en gezien het risico voor bedrijfsvoering en maatschappij als die niet draait, mag je verwachten dat ze daar een redelijk hoge uptime voor afgesproken hebben met een zeer lage RTO.

SLA met een uptime van 99,99 zou in het geval van de EPD (mission critical) niet misstaan denk ik. Daar zijn ze nu wel overheen gegaan.

[mjtdevries]

99,99% betekent nog steeds ruim 50 min downtime.

Maar inderdaad ze zijn over de SLA heengegaan. En dan? Ze betalen voor die maand wat geld terug?
Het afsluiten van een SLA geeft meestal veel minder garantie dan mensen denken.

[indigo79]

En je kan uiteraard alles afspreken, maar als er toch nog iets misgaat (los van of het een complex samenspel van omstandigheden is of een domme fout), betekent dat stukje papier natuurlijk niet dat het ineens wel werkt.

[dmantione]

Ik vind dat een ziekenhuis op zijn minst de plicht heeft zich te nemen informeten hoe het aan de achterkant is gedaan: Als de directie zich achter een papieren 99% kan verschuilen, dan is dat vooral het schoonvegen van het straatje van de directie. Degene die te laat zorg krijgt heeft daar nul komma nul aan. Een directie die verantwoordelijkheid neemt informeert zich hoe de 99% gerealiseerd zal worden en is niet tevreden met een papieren werkelijkheid.

[coolkil]

Vergeef mijn cynische blik… maar zodra het bedrijf een bepaalde schaalgrootte heeft wordt verschuilen achter papieren de standaard. Even uit de lucht gegrepen nummer daarvoor 150 man of groter. Van af dat moment kun je als directie al lang niet meer micro managen. Dan vertrouw je op contracten en afspraken zonder technische inzicht want daar heb je geen kennis en tijd meer voor.

[dmantione]

Je leveranciers controleren betekent niet dat je micromanagement uitvoert. Een directie kan dat prima delegeren. In situaties als deze, vind ik nalaten om dat soort controles uit te voeren en te weten hoe de betrouwbaarheid feitelijk gerealiseerd wordt, vallen onder grove nalatigheid. Die van de vorm die strafbaar is.

[Kcquipor]

Bij 1 van mijn vorige werkgevers hadden we deze oplossing: HA & als Noodoplossing via Veeam bepaalde VM’s replicatie om de 5/10/15min (hangde af van de critical operation status), moest er een rampscenario komen dat HA niet werkt of het laat afweten volledig, dan konden we via Veeam de meeste kritische VM’s weer up & running snel krijgen, bracht soms wel eens een probleem met domaintrusts ☠️

[R_Zwart]

Latency is hier geen probleem, maar de hoeveelheid data die je wilt repliceren wel. Het gaat om miljoenen dossiers waar continue bij een deel wijzigingen worden aangrebracht. Maar goed, biedt je diensten aan zou ik zeggen en ga het "even" HA maken en constateer dat de wereld in werkelijkheid anders is dan vanchter een toestenbord. Ik heb vergelijkbare projecten in Duitsland gedaan en het is niet eenvoudig.

[Reactie gewijzigd door R_Zwart op 25 juni 2026 13:39]

[mjtdevries]

Zo bijzonder is dat niet. Denk bv aan email servers. Miljarden emails waarbij continu bij een deel wijzigingen worden aangebracht. 50GB a 100GB mailboxen zijn heel normaal.

En voor een patientendossier is het niet erg als het 4 sec duurt voor dat op je scherm komt. Bij een mailserver is het onacceptabel.

Met Exchange server was het heel simpel om een HA systeem te maken zonder dat je speciale hardware nodig had en waarbij je dan bv 4 verschillende lokaties had waar je data redundant over verdeeld was.

Groter probleem is waarschijnlijk dat de makers van EPD software hier geen ervaring mee hebben en niet de beste oplossingen bedenken.

[fre0n]

In dit geval zou de HA dus zelfs in de software laag opgenomen kunnen worden

[Piemol]

Misschien staat de directe/gesyncte failover in hetzelfde datacenter, en een evt failover met data 'van gisteren' in een ander datacenter.

Dan is het de vraag wat het handigste is, een paar uur wachten op weer werkende koeling of switchen naar de server met oude data en dat in de loop van de week weer rechtbreien.

edit:
sommige klanten kiezen hier voor: "n het geval van een afgefikt datacentrum vind ik het een goede oplossing om met 'backups van gisteren' een compleet nieuwe server elders op te spinnen en in te richten."

[Reactie gewijzigd door Piemol op 25 juni 2026 12:54]

[SunnieNL]

Hierbij moet je echter wel een goede afweging maken. We praten over een ziekenhuis met een EPD. Dat EPD is mission-critical. Het kost het ziekenhuis miljoenen om alles te annuleren en mogelijk levens als het EPD uitvalt. (verplaatsing naar andere ziekenhuizen, langer wachten, spoed zaken die redirect moeten worden naar andere ziekenhuizen, etc)


Dan is het altijd nog beter als je data van gisteren gebruikt dan dat je helemaal geen data hebt. Die paar uur is ook al bijna een dag. Gisteravond zijn de problemen begonnen en de melding van 12.45u is dat het nog wel enige uren aanhoud. Dan praat je over een dag downtime, niet een paar uur.

[Piemol]

Ja dat snap ik, het is meer een toelichting op 'wat ook zou kunnen'.

Tevens neem je op het moment dát er calamiteiten zijn een beslissing:

• even wachten
• failover (mogelijk 2e failover) scenario inschakelen

Als het datacentrum dan zegt: "nee joh, over een half uur ben je weer online". Dan neem je een andere beslissing als dat de inschatting is dat je er zeker 3 uur uit ligt. Als de problemen in het datacenter opgelost zijn weet je pas wat de beste beslissing had geweest.

[DLabs]

Ben het hier niet mee eens. Het is echt niet lastig om HA te hebben. Je moet je zaken gewoon op orde hebben.

Realistische voorbeeld: Je hebt een tweede lokatie waar je niet krische VM's draait en die uit kunnen als er iets gebeurd.

En we hebben het hier over een ziekenhuis...

[Reactie gewijzigd door DLabs op 25 juni 2026 12:10]

[Coolstart]

Uiteraard zijn er technische oplossingen denk aan Kubernetes of in de hypervisor layer live migration. Echter… dan komt er een license of bedrijfs politiek discussie. (Netwerk en opslag even buiten beschouwing gelaten)

Live migration werkt enkel als de server nog live is. Dus bij een plotse uitval heb je daar niets aan.

In de praktijk hebben alle gevoelige servers een fallback. Zeker medische servers omdat die onder ISO normen vallen. Je moet dat risico op falen en de impact op de patient volledig in kaart brengen. Fail over is zeer makkelijk voor webservices omdat die heel vaak al met loadbalancers werken tussen meerdere servers. De Databse staat vaak gewoon ergens anders.

Bij database voor webapplicaties is dat iets lastiger maar niet onmogelijk. Daarvoor hebben Amazon, Google etc failover services. Uw database wordt dan 100% in sync gehouden via en live link. Als database A uitvalt dan neemt Database B instant over. PgBouncer heeft bijvoorbeeld seamless failover. We zijn niet meer 1998.

Over die 'betalen voor 400 maar 2 gebruiken' Dat kan maar ik begrijp de link niet. Er bestaan toch ook flex abbo's waar je betaald voor max cores + verbuik. Dus Als je 4cores aanduid kan het zijn dat je dan maar af en toe 4cores gebruikt.

EPD's hebben hun eigen databaseregels. Zo mogen de persoonsgegevens en medische niet samen in DB staan. Dus heel die setup vraagt extra aandacht voor DB. Je moet zelfs audits overleven. Da ze die niet niet redundant maken is redelijk onwaarschijnlijk.

Er zijn misschien uitzonderingen met heel oude systemen.

[Cyberpuppy]

Volgens mij moet je bijv. bij Oracle ook echt alles licenseren. Loopt dan wel aardig in de papieren

[Z80]

Nee. het is een AD bericht. Zonder verdere navraag of controle of de bron correct is.

Een datacenter heeft/had koelingsproblemen. En daardoor is er apparatuur plat gegaan. Dit kan 1 systeem zijn. Maar net zo goed een zaal. Of het hele rekencenter.

[editicalu]

Is het een heel datacenter, dan kan je je daar ook op voorbereiden. Eén datacenter is niet heel HA, want een natuurramp (of hittegolf) kan dan ook je hele infra onderuit halen. HA gaat over het niet hebben van een single point of failure.

[GeleKoplamp]

HA gaat over het niet hebben van een single point of failure én een werkende fail-over

(Sorry, daar ging het bij ons onlangs mis)

[YGDRASSIL]

De belgen zeggen dit;

De centrale servers waarop alle medische gegevens worden bijgehouden, zijn oververhit geraakt


https://www.vrt.be/vrtnws/nl/2026/06/25/az-sint-lucas-gent-operaties-hittegolf/

[Reactie gewijzigd door YGDRASSIL op 25 juni 2026 11:48]

[diedie2]

Ik weet een supermarkt die volledig op Windows Server 2003 en SQL Server 2005 draait. En het wachtwoord bestaat uit 2 cijfers.

Al verschillende keren voorstel tot upgrade gedaan maar "het is niet nodig" want "het draait nog" en "dat kost veel".

Wie niet horen wil moet voelen.

[Mayonaise]

Het is een mooi voorbeeld van antifragile. Je kan niet alle risico's voorspellen, maar je kan wel systemen bouwen die zo robuust mogelijk zijn tegen onbekende risico's.

Veel mensen vinden het tegenwoordig blijkbaar moeilijk om zelfs een warme weer als basis risico factor mee te nemen wanneer men cruciale systemen ontwikkeld.

Dus ik denk oprecht dat deze cruciale systemen totaal niet robuust zijn.

[kuurtjes]

Is het OVH?

https://hosted-private-cloud.status-ovhcloud.com/incidents/ht0n04spqjnm

Start time : 25/05/2026 00:40 UTC
End time : 25/06/2026 02:49 UTC
Root Cause : This incident was caused by a cooling system issue.

Na dit te fixen doen ze ook maintenance:

https://network.status-ovhcloud.com/

Start time : 25/06/2026 13:00 UTC
End time : 25/06/2026 18:00 UTC
Service impact : None.
Service improvement : As part of our continuous improvement policy, we will be doing a maintenance on our cooling infrastructure.

[Reactie gewijzigd door kuurtjes op 25 juni 2026 14:09]

[Triblade_8472]

Die digitalisering is geweldig toch. Ze kunnen niet eens tegen een beetje hitte... Ik snap het wel, veel fallback kost klauwen geld terwijl de zorg al zo duur is.

Papier heeft echt ook voordelen. (en ja, ook nadelen)

Ben benieuwd of dit goed gecertificeerd is trouwens als er geen goed alternatief beschikbaar is..

[Groningerkoek]

Met het design van deze ruimten ga je uit van de te verwachten weerpatronen, als het dan toch veel warmer word dan trekt de koeling het niet meer. Dat is heel normaal. Bijna elke fabriek in Nederland heeft de koeling ook al aan moeten passen de afgelopen jaren omdat vooral frequentieregelaars uitvielen.

[Triblade_8472]

Bij het design hoor je rekening te houden met uitschieters. Daarnaast mag ik aannemen dat ze twin-locaties hebben in gebieden met een ander profiel (hoogte, weer, politieke situatie enz)

[Groningerkoek]

Er wordt ook wel rekening gehouden met uitschieters, maar uitschieters duren tegenwoordig zomaar een hele week.

Daarnaast zijn er vaak wel twin locaties, maar als 1 locatie wegvalt is je redundantie dus om zeep en dan voldoen je niet meer aan de "eigen" regels om niet spoed-eisende hulp nog door te laten gaan. De redundantie is vooral om lopende zaken/operaties af te handelen.

[FrostyPeet]

Papier heeft echt ook voordelen. (en ja, ook nadelen)

Ik ken de tijd nog dat ik als patiënt met mijn medisch dossier door het ziekenhuis liep. Daar zat alles in, van rontgenfoto's tot diagnose en behandeltrajecten. Die map gaf ik aan medewerker X, die deed er iets mee, schreef er wat in en gaf de map terug. Dan op naar een andere balie en herhaling. Informatie van derden werd via de fax of post verstuurd, of als telefonische notitie toegevoegd.

Je wil niet weten hoe eng ik dat vond, vanuit het oogpunt van informatie waarborging. Single point of failure, mutaties zonder waarborging en ongeautoriseerde vermenigvuldiging om maar wat te noemen. Geen track and trace.

De digitalisering van de gezondheidszorg heeft (grote) problemen en is duur. Ik vermoed dat bijvoorbeeld het kwijtraken van dossiers nu wel een stuk minder is. Als medewerker X een mutatie maakt, het duidelijk is wat medewerker X deed.

[vlaaing peerd]

Zijn we hier semantisch bezig om uit te vissen wat de redactie nu bedoelt met "de server"?

Misschien ben ik een ouwe lul, maar het woord 'cloud' gebruik ik niet (want cloud is tenslotte gewoon server), ik spreek dus ook altijd van 'de server', ook al bedoel ik een rack vol, of van een datacenter.

[Lothlórien]

En daar heb je nog een punt ook, alhoewel ik juist om die reden eerder geneigd ben aan te geven dat iets op een cluster draait. Bedrijven slaan hun data tegenwoordig ook niet meer op op een enkele harde schijf of SSD. Een beetje beheerder maakt gewoon een RAID opstelling.

Vanuit het cliënt-server model is een server de entiteit waar verbinding mee gemaakt wordt en die de gevraagde data kan leveren. Of dit nu 1 computer is, 10 computers, of zelfs dezelfde computer als de cliënt maakt dan niet uit.

Doet me denken aan de semantische discussie met collega's of cloud software op 10 on-premises barebone machines wel de term "cloud" waardig is.

[mrdemc]

en of barebone wel de juiste term is ?

[Marve79]

Oververhitting van 1 server in Parijs, really?

[Glashelder]

Uit de bron:

Er hebben zich gisteravond problemen voorgedaan in het internationaal datacenter van onze EPD-leverancier door de aanhoudende hitte

Problemen in het datacenter dus. Niet een server. Beetje flauw dit zo te zien..

[Marve79]

Tja er staat toch duidelijk één server in het artikel. Beetje vreemd dat je dan zelf de bron moet gaan zoeken voor het echte probleem of het uit de reacties moet halen.

En ook: Op de getroffen server staat het elektronisch patiëntendossier.

Dat laat ook al zien dat het om een enkele server gaat, blijkbaar is er geen redundantie?

[Reactie gewijzigd door Marve79 op 25 juni 2026 10:13]

[Paul]

Een EPD draait erg vaak op één database-server. Naast die database-server heb je vaak wel een hele stapel andere servers (eentje met een kopie van de database om rapporten te offloaden, een stapel webservers / applicatieservers, printservers, fileservers, etc.), maar slechts één 'main' database server. Pas als je zo groot bent dat die ene server het niet trekt ga je naar manieren kijken om dat verder te verdelen. Dat kost echter klauwen met geld (licenties, meer hardware, etc.) en heeft ook weer nadelen. Zolang je dat met één database-server af kan, doen!

Dat staat echter compleet los van de redundancy. Ik heb geen idee welk systeem ze gebruiken en hoe een failover van de ene naar de andere server eruit ziet, maar dat zou mijns inziens geen uren hoeven duren. Ik werk ook voor een ziekenhuis, en als ik het even heel ruim neem dan duurt dat een half uur, maximaal. Als die failover bij deze ziekenhuizen zo lang duurt dan zou ik als ik hun was kijken of dat korter kan, maar ik ken uiteraard de ins en outs niet. Als management er bijvoorbeeld niet voor wil betalen dan kun je als IT'er ook niet veel meer aan doen.

[Marve79]

Een failover een half uur? Als je een DB server in 1 DC hebt een DB server in een ander DC dan duurt dat max 5 seconden ofzo, maarja voor die redundancy moet je wel betalen idd. Maar je zou verwachten dat een groot ziekenhuis dat wel op kan hoesten.

[Paul]

5 seconde werkt misschien voor bepaalde softwarepakketten, maar niet voor de EPD's die ik ken. In ons geval kost alleen al de DNS aanpassen en alle application pools op alle webservers recyclen minstens een minuut, en dat staat nog los van alle stappen die je op de database-servers zelf moet doen. En die wil je echt wel zorgvuldig doen, want er is *niemand* gebaat bij het af te willen raffelen om zo een minuut te besparen, als je daarna uren aan het puinruimen bent, je data corrupt is, en men nog steeds niet kan werken, omdat je het zo nodig snel snel snel wilde doen en een fout maakt of de sync nog niet klaar was.

We doen het niet zo vaak (en ik zit er niet zo kort op) dat ik er echt goede getallen van heb, vandaar dat ik conservatief aangaf dat het maximaal een half uur duurt, in de praktijk is het flink minder, maar 5 seconde kost het absoluut niet.

[DinX]

Klopt. Mensen vergeten dat in de praktijk aan die database nog tientallen (bij ons 700) andere pakketten gekoppeld zijn, vaak met iets als een Mirth Connect en dergelijke ertussen om alles met elkaar te laten spreken.

Kan je wel lekker failovers in gang gaan zetten en dergelijke, in de praktijk lost dat weinig op.
Je inschrijvingssysteem is inmiddels reeds naar de noodoplossing overgeschakeld, werklijsten voor radiologie zijn inmiddels al manueel opgeladen (of ze zijn manueel bezig op de toestellen zelf).

Dat geeft uren tot dagen aan opruimwerk om het noodinschrijvingssysteem terug gelijk te trekken met het EPD, bedbewegingen gelijk te trekken, PACS informatie manueel koppelen aan het EPD, labo resultaten,...

Mensen hebben echt geen flauw idee hoe complex het is binnen healthcare. Op dat vlak is healthcare meer te vergelijken met een containerterminal of distributiecentrum dan met een klassiek bedrijf.
Als daar bepaalde systemen uitvallen kan je ook wel allerlei containers op een boot beginnen laden in de tussentijd, of je order pickers lekker laten door doen. Maar ook daar gaat er uren/dagen aan opruimwerk en controles uit voort komen.

Dan is het soms gewoon beter om een halve dag operaties (zijn voor het overgrote deel toch geplande, niet dringende) schrappen dan in nood modus lopen verder doen.

[MrDaViper]

In ons geval kost alleen al de DNS aanpassen en alle application pools op alle webservers recyclen minstens een minuut, en dat staat nog los van alle stappen die je op de database-servers zelf moet doen

Dan heb je een volledig foute setup. Je wil naar een shared ip overschakelen waar je - indien nodig - manueel het IP verzet naar de backup node.

In een normale cluster is dat zelfs niet nodig, want je hebt connectie naar je listener die je doorstuurt naar de werkende backend node, gelijkaardig aan een active/passive loadbalancer setup.

Zelfs met connecties vanuit Mirth of andere message brokers is daar geen enkel probleem mee en is de failover bijna instant met minimale data loss als je de database cluster correct opgezet hebt.

[Paul]

Ik zal aan een van 's werelds grootste EPD-leveranciers doorgeven dat hun setup volledig fout is...

Of misschien ken jij niet alle ins en outs en roep je maar wat. Er gaan miljarden om in de business, en downtime kan letterlijk levens kosten. Ik denk dat ze er iets beter over hebben nagedacht, en hun product een klein beetje beter kennen dan dat jij dat nu doet.

[MrDaViper]

Misschien eens nadenken over wat je zegt..

downtime kan letterlijk levens kosten

Maar downtime omdat je database niet ten alle tijde bereikbaar is en je die even moet restoren op een nieuwe server omdat de oude gecrashed is kan dan wel?

Chipsoft is zeker en vast niet de grootste EPD leverancier, ze beweren misschien van wel, maar dat zijn ze niet.

De meeste grote ziekenhuizen draaien op KWS die in UZ Leuven ontwikkeld wordt met Cegeka als partner en ook in UZ Leuven gehost staat.

[Paul]

Wie heeft het nu weer over restoren? Ik in ieder geval niet, ik fail gewoon over naar de passieve node...

[Paul]

...behalve dan dat we geen MSSQL gebruiken voor het EPD En IIS is erg stabiel bij ons...

[DinX]

Als infrastructuur medewerker in 1 van de grotere regionale ziekenhuizen hier kan ik je vertellen dat het niet allemaal zo simpel is als even de database failoveren.

In ons geval spreek je over een 700-tal verschillende toepassingen die in veel gevallen gekoppeld zijn aan dat EPD. Zaken als het labo, inschrijvingen, radiologie,... Die zijn allemaal verbonden via message brokers als een Mirth Connect en dergelijke. 1 wijziging in het EPD kan tientallen andere processen in gang schieten in vele andere toepassingen, en omgekeerd.

Als er bepaalde koppelingen voor een langere tijd wegvallen gaat er nadien een heel deel manueel werk moeten gebeuren, controles, zaken manueel koppelen,...
Je gaat dus niet zomaar beslissen om een failover te doen. Soms levert dat nog meer problemen op dat bijvoorbeeld een halve dag aan operaties schrappen.

Dezelfde opmerkingen krijg je bijvoorbeeld ook bij artikelen bij ransomware en dergelijke. Klassieke opmerking is "zet je immutable backup terug". Nee, dat zal niet zomaar gebeuren. Daar gaan ontzettend veel afwegingen aan vooraf.

[bazzi]

Je kan toch gewoon een master master database draaien? Dus dan draait het over verschillende servers. Je kan zelfs het in meerdere datacenters doen, alleen moet je goed opletten op split brain…

En ja ik werk al jaren aan een applicatie die zo draait in meerdere datacentra…

[Marve79]

Idd dat kan ook nog, ik heb dat vroeger nog gedaan met Galera en MariaDB over 3 of zelfs 5 nodes wereldwijd (voor game servers).

[MrDaViper]

Een EPD draait erg vaak op één database-server

Niet correct. Een EPD draai je over een cluster van database servers, of active/active of een failover cluster.

Als je een EPD, iets wat zo kritisch is, op één enkele database server draait ben je wel erg fout bezig.

[Paul]

...heb je de tweede alinea ook gelezen? Heb je de eerste alinea überhaupt gelezen? Of ben je gestopt met lezen na deze ene zin?

[MrDaViper]

ik heb alles gelezen en je antwoord is volledig mis.

De kostprijs van een deftige cluster setup tov data verlies of het uitvallen van gans je EPD en je ziekenhuis platvallen valt te negeren .

En ja, ik weet waar ik over spreek, jaren consultant geweest in een groot ziekenhuis die het wel correct opgezet heeft en waar downtime geen optie is.

[Paul]

Ah, je hebt het dus niet gelezen, duidelijk. Ga dat eerst maar eens doen... Hint: het EPD draait niet op de passieve of failover clusternode...

Het kan active/active in sommige gevallen (heel erg afhankelijk van welke databasesoftware je precies gebruikt), maar noch Chipsoft noch Epic gebruiken dat.

[MrDaViper]

je hebt duidelijk geen weet waarover je praat..

Geen enkele applicatie kan op een passive of failover cluster node draaien.

ELK software pakket dat een SQL database nodig heeft kan overweg met failover en active/active clusters.

Óók Chipsoft kan overweg met MSSQL database clusters en active/active clusters, echter weten de vertegenwoordigerdames niet over wat ze bezig zijn.

[bzuidgeest]

Het nieuws is niet de uitval in het algemeen, maar dat een ziekenhuis niet verder kan omdat een server het warm krijgt. En dat betreft een enkele server.

Wellicht kan je hieruit afleiden dat het ziekenhuis naar een halterlocatie moet kijken en niet op 1 server vertrouwen.

[sjakie66]

Het gaat om de leverancier!

[bzuidgeest]

Dat vind ik niet. De storing is iets wat altijd iedereen kan gebeuren. Het nieuws is dat een ziekenhuis, een cruciale zorg club, niet voorbereid is op uitval.

[wiseger]

Precies. Daarom hen je als organisatie continuteits plannen en rampen herstel plannen. Die je jaarlijks test.

Uitwijken naar een ander data center is daar onderdeel van. Dus hier had gewoon het rampen herstel plan uitgevoerd moeten worden zodat de impact minimaal geweest zou zijn.

[Mr.Analog]

De levernacier is niet verantwoordelijk voor een back-up, enkel voor herstel en beschikbaarheid zoals opgestelde eisen tijdens de aanschaf van de server*. Het ziekehuis is verantwoordelijk voor buisness continuity.

*Als hier een 99.999% (niet ongebruikelijk) voor is opgegeven dan kun je stellen dat de leverancier inderdaad moet zorgen dat de systemen zeer snel hersteld zijn. Dit lijkt in deze dan niet gehaald, maar dat maakt het ziekehuis nog wel verantwoordelijk voor de continuiteit van de zorg.

[Reactie gewijzigd door Mr.Analog op 25 juni 2026 11:05]

[MrDaViper]

De levernacier is niet verantwoordelijk voor een back-up, enkel voor herstel en beschikbaarheid zoals opgestelde eisen tijdens de aanschaf van de server*

Dat hangt volledig af van het contract met de leverancier.

Het kan evengoed een SAAS pakket zijn, waar de leverancier dan wel volledig verantwoordelijk is.

[Mr.Analog]

I stand corrected, klopt helemaal! De back-up kan natuurlijk onderdeel zijn van het contract.

[turbojet80s]

Juist!

[michelr]

Je plant voor beschikbaarheid, veerkracht en uitwijk, maar dat betekent niet dat er gegarandeerd altijd uitgeweken kan worden.

[bzuidgeest]

Nee shit happens. Maar een zo belangrijke server kan op zijn minst een tegenhanger op een andere locatie hebben. Dan heeft een incident met de ene geen gevolgen voor de o zo belangrijke zorg.

[michelr]

Het overkomt de besten soms ..
https://londondaily.com/heatwave-forced-google-and-oracle-to-shut-down-computers

[Lothlórien]

Waarschijnlijk wel, onder water, zal dat ina diverse vertalingen verloren zijn gegaan omdat de leek dat niet weet.

Grote kans dat het dossier draait op een een cluster virtuele machines en dat die machines dan weer draaien op één of meerdere servers in het getroffen datacentrum, eventueel zelfs door meerdere datacentra met een mirrored site.

Dat ga je natuurlijk niet allemaal uitleggen in een nieuwsbericht. Eén server klinkt wel hopeloos ouderwets.

[n4m3l355]

Echter als er sprake is een cluster over meerdere servers over meerdere locaties, hoe leg je dit uit? Het doel van een dergelijke opstelling is toch dat juist dit soort situaties worden voorkomen? Ergens lijkt het dat door een single point of failure de hele handel op z'n gat ligt.

[Glashelder]

Ja ik bedoelde dus flauw van de schrijver, sorry

[brutus0]

Ik vind het gewoon slecht dat je medische servers hebt en dan niet genoeg kapaciteit op je koeling. Al is het een andere klant dan is het van oke het gaat even niet. Maar dit zijn gewoon mensen die de operatie nodig hebben, die staan maanden in de wachtrij en dan kan het niet omdat de servers een beetje warm worden.

[joker1977]

Het zijn geen "medische servers". Het zijn gewoon servers in een datacenter (in Parijs).

Dat datacenter heeft ongetwijfeld een SLA en het ziekenhuis / EPD-leverancier heeft ongetwijfeld ingekocht op basis van een bepaalde SLA.

[brutus0]

Meestal is het dat de Medische servers net als overheid servers afgesloten zijn van de rest van de servers. Omdat ze in een speciale kooi zitten zou je zeggen dat dat bij de kritieke servers de koeling wat wordt opgeschroefd.

[NielsFL]

Ik weet niet waar je dat denkt te vinden, maar in Nederland is dat niet de norm. Er zijn weliswaar partijen die zich in deze datauitwisseling specialiseren maar die verbindingen lopen uiteindelijk gewoon over het normale internet.

[FreezeXJ]

Het is gewoon een commerciele tent he, die doen een kosten-baten-analyse, en voor die 3 dagen in het jaar dat het zo absurd heet is ga je blijkbaar niks extras doen, behalve hopen dat je hoster z'n huiswerk gedaan heeft. Mijn gok is dat hun backup bij dezelfde toko zit, en in hetzelfde datacenter... en dan ben je soms de Sjaak. Met wat geluk staat er nog iets in contracten zodat het ziekenhuis centjes terugkrijgt, maar als patient vrees ik dat het gewoon pech gehad is. Geen vergoeding omdat je afspraak is afgezegd. Zodra dat verandert gaat 1 de zorg duurder worden (want schadevergoedingen zijn duur en iemand moet dat betalen) en 2. gaan dit soort contracten op de helling.

[J_van_Ekris]

Het is gewoon een commerciele tent he, die doen een kosten-baten-analyse, en voor die 3 dagen in het jaar dat het zo absurd heet is ga je blijkbaar niks extras doen, behalve hopen dat je hoster z'n huiswerk gedaan heeft. Mijn gok is dat hun backup bij dezelfde toko zit, en in hetzelfde datacenter... en dan ben je soms de Sjaak.

In betrouwbaarheids- en bedrijfszekerheids-kringen gaan we standaard uit van 150 kilometer ruimtelijke scheidng om onafhankelijkheid van falen ten gevolge van regionale problemen aan te kunnen nemen. En dan heb je het over langdurige stroomuitval, (bos)branden, overstromingen, chemische luchtverontreinigingen als gevolg van een ongeval (chloortreinen) etc.. Dichterbij kan, maar dan wordt het een gerichte analyse waar de datacenters staan, en hoe dijkringen lopen, hoe het grid er uitziet, etc.. Een hittegolf met deze extreme omvang overspant die 150 kilometer makkelijk. Heel Frankrijk was gewoon bloedheet. Dus al had je een perfecte colocatie, die heeft gewoon exact hetzelfde probleem: je kunt je warmte wel onttrekken, maar je kunt hem domweg niet kwijt....

[Jacco011]

Ik snap niet waarom data dan afhankelijk is van een enkele datacenter en waarom er geen hot-standby is op een andere locatie. Naast hitte zijn er genoeg andere scenarios waarom een locatie offline kan gaan.
Trouwens kost dit het ziekenhuis zelf ook geld, want nu hebben artsen minder werk en wordt er vermoedelijk afgeschaald.

[Stijnvi]

Parijs had gisteren ook last van een stroomstoring doordat er zoveel vraag was naar koeling. Kan dus goed zijn dat dat de achterliggende oorzaak is. Wel voldoende koeling, maar geen stroom om die koeling te laten werken.

https://www.lemonde.fr/en...ord-heat_6754821_114.html

[J_van_Ekris]

Ik vind het gewoon slecht dat je medische servers hebt en dan niet genoeg kapaciteit op je koeling. Al is het een andere klant dan is het van oke het gaat even niet.

Klinkt allemaal heel makkelijk. Besef dat gisteren de heetste dag ooit in Parijs was (zie https://www.lemonde.fr/en...-horizon_6754845_114.html). Een koelsysteem kan perfect werken, maar als je je warmte nergens kwijt kunt omdat de buitentemperatuur gewoon te hoog is, keldert je koelcapaciteit gewoon enorm. En dan helpt een redundante koeling ook niet echt (want zelfde probleem). We noemen dit in vaktermen ook wel een "Common Mode Failure". Dit is gewoon de achillehiel van elke installatie die veel warmte produceert en tenzij je krankzinnig ver overdimensioneert is het niet te voorkomen.

Optie is misschien warmteproducenten (servers) afschalen of uitzetten om bedrijfskritische klanten veilig te stellen. Maar dat is iets wat in een hostingwereld niet echt done is, al is het maar omdat elke klant zijn systeem voor zichzelf bedrijfskritisch vindt.

[xxs]

Ach, een niet IT onderlegde woordvoerder die een bericht moet uitsturen.

[FreezeXJ]

Dat mag, maar dit soort schriftelijke dingen kun je even langs een techneut halen. Of misschien heeft communicatie besloten dat ze gebruikers (die vaak ook niet technisch zijn) niet lastigvallen met technobabble. Voor nadere info en tech-sites hebben ze dan de mail.

[vverbeke]

Diezelfde techneut is waarschijnlijk eerder bezig met alles weer up and running te krijgen.

Verder wordt in veel organisaties nogal makkelijk vergeten de expertise van IT in te roepen zodra het niet over de harde IT gaat, persberichten nalezen op accuraatheid is daar bijvoorbeeld eentje van.

[GertMenkel]

Nee. Volgens het ziekenhuis:

Er hebben zich gisteravond problemen voorgedaan in het internationaal datacenter van onze EPD-leverancier door de aanhoudende hitte.

De oorzaak voor het ziekenhuis is dat de server oververhit raakte, maar het datacenter in het algemeen lijkt onder de warmte te zijn bezweken.

[Lord Anubis]

De auteur van dit artikel had het ook een beetje warm. Moeilijk om het eigen servertje koel te houden. Zoals onze koningin het ooit zei ”Het was een beetje dom”

[Ximon]

De cloud is gewoon iemand anders' computer

[pcmulder]

Iemand een idee welke provider dit is? Je zou verwachten dat er redudantie ingebouwd is toch?

[simplicidad]

Vanochtend moest ik mijn moeder, die gewond was geraakt, naar de spoed brengen. Bij de ziekenhuisapotheek in Roeselare liep het ook mis, omdat ze het dossier (vermoedelijk het patiëntendossier) niet konden openen om haar medicatie voor te bereiden.

Enkel nog interne systemen werkten en werd het opgelost met de ouderwetse telefoon. Zei nog al grappend dat er wel ergens servers zullen zijn overbelast met dit weer.

[Dekar]

Wij hadden bij ons MKB bedrijfje zelfs een off-site failover server staan voor kritische bedrijfsprocessen. Draaide stukken trager, maar dan konden we tenminste doorwerken. Was die er hier helemaal niet?

[Prince]

In Parijs?
"De server" - eentje dus?

Je zou verwachten dat dit redundant is en op meerdere fysieke lokaties.

Kunnen ze niet samenwerken met Gasthuisberg? Die hebben on site toch bijna een datacenter?

[keejoz]

als je "bijna een datacenter hebt" dan heb je dus eigenlijk helemaal geen datacenter. Hoe lost dit het probleem op?

[Prince]

Ze hebben een klein datacenter (1900m²), maar voor eigen intern gebruik.
Servers, backup power, koeling, etc... enkel verkopen ze geen plaatsjes of dedicated servers gezien dit allemaal om ziekenhuis-gerelateerde zaken gaat.
MyNexus draait daar dacht ik; een applicatie die steeds meer en meer ziekenhuizen in Belgie gebruiken.

Mijn "bijna" ging dus over de interpretatie van wat een datacenter een datacenter maakt. Oppervlakte? Het verkopen van servers? Redundancy? 24/7 on-site support? Security? Hoeveelheid servers? Wanneer is het een IT gebouw en wanneer is het een datacenter?

[Tha Render_2]

Ze gebruiken een externe leverancier voor hun EPD en die heeft dat draaien in een cloud/datacenter in Parijs.

[ThaStealth]

Dat het redundant is (hoop ik dan voor ze) wil niet zeggen dat de kosten ook opwegen tegen de baten. MIsschien was duidelijk van het datacenter dat ze binnen x uur de koeling weer op orde zouden krijgen, en zou een failover betekenen dat ze evenveel tijd kwijt waren + ooit nog eens terug moesten. (+ alle aanvullende kosten voor het overwerk van IT teams).

[svennd]

Ook UZA heeft een onsite servers (en ruimtes), sommige zaken zijn echter door toeleveranciers ...

[Hansie9999]

Dit dus,

Hoe belachelijk is dat nu ??

Mijn eigen persoonlijke data staat bij mij thuis EN op het werk 20km verder op, maar de patiëntendata (sowieso al mogelijk niet echt ok dat privacy gewijs dit ergens in frankrijk zit ??) heeft een ziekenhuis met toch wel een iets groter IT budget dan ik op slechts 1 plaats staan , niet in eigen beheer , geen redundantie op een tweede locatie en NIETS lokaal staan ??

Mijn tandarts (een heel toffe oude man) heeft wel de laatste nieuwe high tech apparatuur om mee te werken , maar de patiëntgegevens zitten nog echt in een fichenbak , is natuurlijk ook totaal zonder backup, maar zelfs als alle electriciteit uitvalt kan die bij kaarslicht nog aan mijn patiëntdata