Diverse ziekenhuizen hebben ict-storing door onbekende oorzaak - update

Diverse Nederlandse ziekenhuizen hebben te maken met een ict-storing door een nog onbekende oorzaak. Door de storing zijn dossiers niet in te zien en werken aanmeldzuilen in de ziekenhuizen niet.

Het gaat om het Isala-ziekenhuis in Zwolle, de ZorgSaam Zorggroep in Zeeuws-Vlaanderen en Noordwest Ziekenhuisgroep in onder meer Alkmaar die met de storing te maken hebben, meldt de NOS. Patiëntenportalen van het Diakonessenhuis in Utrecht, Sint Jans Gasthuis in Weert en het Dijklander Ziekenhuis in onder meer Purmerend hebben ook last van een storing.

Noordwest zegt dat de storing ligt bij dienstverlener ICTZ, maar die ontkent dat de storing bij dat bedrijf vandaan komt. Daardoor is het onduidelijk waardoor de storing komt en bij wie het probleem precies ligt. Er is ook geen prognose over wanneer alles weer online zal zijn.

Update 13:56: Chipsoft, leverancier van de EPD-software, zegt in een reactie dat de oorzaak niet bij hen ligt. "Het is extern en we hebben ook geen zicht op wanneer er een oplossing is." ICTZ heeft nog geen gehoor gegeven aan een verzoek om terug te bellen, maar zegt tegen NHNieuws dat het ligt aan de provider van het datacenter. Wat daarmee gebeurd is, is nog niet bekend.

Reacties (144)

[ovm]

Ik werk zelf in een ziekenhuis als beheerder van het EPD (HiX) en het Patiëntenportaal. Het EPD werkt gewoon bij ons. Het Patiëntenportaal is niet bereikbaar. Patiënten kunnen dus hun eigen dossier niet inzien, zelf geen afspraken maken, ect.

Het verwijzen van de huisartsen naar de ziekenhuizen loopt vertraging op. Normaal gaat dit automatisch, nu komen de verwijzingen in een zogenaamde fallback en worden deze handmatig in het EPD gezet.

[Technomania]

Ik heb meteen even getest en als ik wil inloggen in Mijn Noordwest krijg ik een runtime error

edit: Update 15h22. Inmiddels kan ik weer inloggen dus ik denk dat het (gedeeltelijk) is opgelost.

[Reactie gewijzigd door Technomania op 22 juli 2024 16:45]

[sebastienbo]

hmm runtime error wijst op een software probleem, niet op een infrastructuur probleem.

Iemand heeft iets gewijzigd zonder change en durft niet toe te geven :-)

[pasz]

Of slecht geschreven software die niet kan omgaan met een fout in de onderliggende infra.

[sebastienbo]

We spreken hier over een webapplicatie, niet over binaire code

Bij binaire code die indruisd tegen alle normen, waarden ,standaarden en design patterns, kan inderdaad een infrastrctuur probleem ook de software van zijn melk brengen. Denk bijvoorbeeld aan direct memory access dat je in C taal kan schrijven (pointers)

[rolandlub]

Ik programmeer veel api koppelingen en heb ook 1x de fout gemaakt in de lengte van een database waarde.
Ging maanden lang goed totdat de waarde schijnbaar toch langer werd.
Bij web applicaties is het zeker niet perse het geval dat wanneer het draait, het blijft draaien.
En dan debuggen......

[pasz]

Niet alle web-apps zijn clientside....
En een null checkje vergeten kan al een runtime error geven.

[TheDutchChief]

Precies dat, bij ons ligt er altijd nog een (geoefende) papieren versie klaar om de spoed etc. gewoon door te laten gaan. Is misschien lastig voor een patiënt dat ie even niet bij zijn gegevens kan, maar gevaarlijk is het niet.

[CptMorgan]

Dat klinkt als een verstoring in (een onderdeel van) het EPD/Patientenportaal. Voor zo ver mij bekend gebruiken de genoemde ziekenhuizen allen hetzelfde EPD genaamd ChipSoft HiX. Het NOS zegt: "Verschillende ziekenhuizen in Nederland hebben te kampen met een ICT-storing. Daardoor kunnen patiënten zich niet digitaal aanmelden bij het ziekenhuis en kunnen ze hun online dossier, met daarin bijvoorbeeld ook uitslagen van het laboratorium, niet inzien. Ook huisartsen kunnen door de storing niet inloggen bij een aantal ziekenhuizen.".

[Reactie gewijzigd door CptMorgan op 22 juli 2024 16:45]

[subby_nl]

Nee dit is niet juist, en stemmingmakerij.

HiX draait in veel meer ziekenhuizen, waar nu geen problemen zijn.
Wat de ziekenhuizen die nu storing gemeen hebben is de hostingprovider.

[Skyaero]

Woordvoerder van ICTZ lijkt dat te bevestigen:

"Wij hosten bij een datacenter", aldus de ICTZ-woordvoerder. "Dat datacenter wordt bevoorraad (sic) door een provider, en die provider kampt met problemen." Om welke provider het gaat, wil ICTZ niet kwijt. Ze bevestigt dat online communicatie met patiënten door de storing niet mogelijk is, maar dat noodzakelijke zorg 'kan worden blijven uitgevoerd'.

https://www.nhnieuws.nl/n...at-en-geen-videoconsulten

[Robinski]

Een trace naar de diverse patiënten portalen laat zien dat verkeer richting Equinix gaat..

[heuveltjes]

En Equinix had een storing in haar transport netwerk vanochtend,,,

[johnkeates]

Yikes, zou het nog om een legacy setup met fysieke servers gaan?

[FreezeXJ]

Ik weet niet welke setup jij kent waar er geen fysieke servers meer onder zitten, maar zelfs als je keurig 'gevirtualiseerd' of in de 'cloud' zit, staat er ergens de fysieke server, en kan iemand daar de verkeerde netwerk-kabel eruit trekken... Of... iemand kan de (virtuele) config zo verkloten dat je mooie virtuele bakje alsnog platligt.

[Horatius]

Als je echt helemaal in de 'cloud' zit en je servers dynamisch huurt en opstart zou het missen van een ethernet kabel geen probleem moeten zijn. Aangezien dan er gewoon een server faalt, dus de load gaat omhoog dus er moet er eentje bij.

Denk alleen niet dat ze zover geïntegreerd zijn.

[Rolfie]

Tenzij het je database server betreft?

[K-aroq]

Er zijn nog niet zo veel datacenter die al zo ver zijn.

[TgR_KILLER]

Ja een MS of Amazon cloud zal je dat wel hebben. Maar enig ander 'gewoon' DC is vast nog niet zo ver, En als jij netjes een bak VmWare machines heb draaien b.v. op wat voor hardware dan ook, dan gaat die echt eronder uit als je een issue hebt.
Het is IT, er kan altijd wat stuk xD

[Antipater]

Ik weet niet welke setup jij kent waar er geen fysieke servers meer onder zitten, maar zelfs als je keurig 'gevirtualiseerd' of in de 'cloud' zit, staat er ergens de fysieke server, en kan iemand daar de verkeerde netwerk-kabel eruit trekken... Of... iemand kan de (virtuele) config zo verkloten dat je mooie virtuele bakje alsnog platligt.

Dit gaat niet op voor moderne applicaties. De setup waarvan ik aanneem dat johnkeates naar verwijst maakt gebruik van cloud services. Die zijn ofwel standaard redundant uitgevoerd, ofwel door een goede architectuur relatief eenvoudig redundant te krijgen. Zelfs als dan een heel datacenter ontploft blijft de applicatie overeind.

In de cloud is dit eigenlijk de standaard, de norm. Het feit dat je applicatie onderuit gaat vanwege een uitvallend datacenter verraadt dat je wat oudere architectuur hebt die niet aan de moderne standaarden van beschikbaarheid voldoet.

[eborn]

Dat kan natuurlijk ook gewoon een budget kwestie zijn. Dat iets kan wil niet zeggen dat het financieel haalbaar is.

[stimpak]

Mooi vertekend beeld, maar laten we voorop stellen dat in het geval van patientengegevens er niet slechts aan uptime-eisen voldaan moet worden, maar dat beveiliging van de data en helemaal de integriteit daarvan absoluut minstens net zo belangrijk zijn. Als je dit alles op EC2 of whatever zou zetten dan kan geen enkel bedrijf, noch de hosting, noch de cloud-provider deze dingen 100% garanderen, dus het ligt natuurlijk wat ingewikkelder hier dan simpelweg "durrr zitten ze niet in de cloud?".

[johnkeates]

Ik ken setups als AWS, Azure, GCP, IBM, Oracle enz. Maar zelfs de kleintjes zoals het Nederlandse TransIP stelt je in staat om niet met je fysieke datacenter bezig te zijn (wat gewoon geen core business is tenzij je een provider bent of van het formaat CloudFlare/Facebook/Twitter enz).

Het gaat me er om dat een SaaS leverancier zelf dus blijkbaar met fysieke capaciteit bezig is en niet met multi-region en multi-zone (per region) redundancy aan SDx werkt. Dat is gewoon 90's mentaliteit om nu met iets te werken wat die abstractie niet kent. Het is beschikbaar, betaalbaar en schaalbaar. En ja, er zitten nog steeds limieten aan, je kan niet opeens 100000000000 CPU cores tegelijk starten, maar in elk geval wel meer dan wat je als zelfstandig bedrijf kan.

[CptMorgan]

Maar dan klopt mijn reactie wel alleen moet ik hem iets beter verwoorden; het gaat waarschijnlijk om een verstoring bij de de hostingprovider van het EPD en/of patientenportaal. Toch? Of zit ik verkeerd .

[DialOut]

De tekst wekt de suggestie dat de leverancier van het EPD en/of portaal een probleem heeft. Dit is echter niet waar, de leverancier (Chipsoft) draait in grootdeel van de NL ziekenhuis en er is maar een beperkt aandeel wat een storing heeft.

Zowel het patientenportaal als de aanmeldzuilen werken obv webapplicaties die de betreffende ziekenhuizen (blijkbaar) elders hosten via ICT-Z. De storing zal waarschijnlijk bij het datacenter zitten, zoals @subby_nl aangeeft.

[jip_86]

Een storing bij de hostingprovider is naar mijn idee totaal iets anders als een verstoring bij de leverancier van het product. Volgens nu.nl levert ICTZ aan 48 ziekenhuizen (link) dat kan al snel de indruk wekken dat het aan de leverancier van het product zit.

[tweaknico]

Het hangt er maar net vanaf hoe het geregeld is...

Paas, Saas: ICT leverancier verantwoordelijk voor alles wat er achter zit.
Als de ziekenhuizen direct zelf een contract met de Hosting provider hebben .. de hosting provider.
Als ze on-premises draait is het ziekenhuis volledig verantwoordelijk.

[Reactie gewijzigd door tweaknico op 22 juli 2024 16:45]

[Robinski]

ICTZ host zeker niet voor alle ziekenhuizen, zijn zat ziekenhuizen die zelf dingen hosten.

[Boogie]

Juist, veel ziekenhuizen hebben ChipSoft HiX maar hun 'patientenportaal' uitbesteed aan ICTZ of Intermax. (De hostingpartij van) ICTZ heeft nu blijkbaar een storing waardoor van diverse huizen het portaal niet bereikbaar is.
Dat zelfde portaal heeft ook een aantal functionaliteiten die je intern kunt gebruiken zoals aanmeldzuilen en schriftelijke anamnese (vragenlijsten), dus dat verband is logisch.

Overigens is het heel logisch dat ziekenhuizen het portaal uitbesteden; het is op basis van sharepoint en dat kan je licentie-technisch beter laten hosten dan zelf licenties voor aanschafffen. Ook is er voor het portaal veel specialistische kennis nodig, onder andere voor de DigiD integratie.
Daarnaast moest bij alle ziekenhuizen de implementatie snel, als je op tijd klaar was dan kreeg je VIPP subsidie, en was daarom uitbesteden aan een partij met ervaring vaak de beste keuze.

[Reactie gewijzigd door Boogie op 22 juli 2024 16:45]

[Robinski]

Die SharePoint setup is inderdaad nogal complex...

Maar naast volledig hosted afnemen kun je als ziekenhuis ook alleen het opzetten en (remote) beheer/ondersteuning uitbesteden. Ben ik even blij dat bij ons destijds daar de keuze op gevallen is.

[Senaxx]

Ik ben zelf ook werkzaam in een ziekenhuis en ook geen problemen met Chipsoft HiX EPD. Wij hebben het EPD dan ook on-premise staan.

Het lijkt er op dat inderdaad alleen de aanmeldzuilen en het patienten portaal waar patienten hun eigen informatie kunnen inzien momenteel niet werkt. Voor medewerkers die zorg moet verlenen is er niets aan de hand met het EPD.

[TRAXION]

Man man man wat een gepruts mooi al die gecentraliseerde systemen met dit als gevolg.

Voor bepaalde toepassingen hartstikke mooi maar met een ziekenhuizen kunnen de gevolgen serieuze gevolgen hebben.

Heb vroeger bij het dijklander ziekenhuis op de it afdeling gezeten nog voordat de term cloud bestond 90% van de websites nog uit web 1.0 bestond.

2 gespiegelde server ruimtes en een uptime die niet te verslaan was in de tijd dat ik daar werkte 1x meegemaakt dat het netwerk plat lag door een hangende dhcp server welke na 2 minuten gereboot was 5 minuten downtijd voor minder dan 1% van de gebruikers.

Maar kosten is alles ict werd toen al als kostenpost gezien en aangezien er toen een zelf ontwikkeld pakket draaide wat onderhouden en ontwikkeld werd door een 20 tal medewerkers werd dit te duur.

Ik ben voor de reorganisatie zelf opgestapt maar ben later tussendoor nog weleens langs gelopen als ik toevallig daar moest wezen.

Het hele ontwikkelteam wat echt op de goede richting zat uit elkaar getrokken.
Netwerk beheerders met een gigantische kennis welke andere taken kregen.

Eigen data servers extern een probleem inpandig niet meer direct aan kunnen pakken

Ik snap dat dit efficienter is in de kosten maar of het ook perse beter is heb ik mijn twijfels over.

[COW_Koetje]

Dit is de typische reactie die ik zovaak hoor vanuit de techneuten. Wij weten het allemaal en laat ons nou maar met onbeperkt budget iets bouwen dan is het altijd goed.

Maar we (ja de mensen van IT) doen het voor een bedrijf met bedrijfsprocessen. Die bedrijfsprocessen worden geautomatiseerd en daarmee blijft het bedrijf eigenaar hiervan. Ze mogen dus bepalen in een SLA wat de dienstverlening moet zijn. Als je techneuten laat bepalen wat de RPO/RTO is dan moet alles 24/7 over 3 datacenters (of onprem) plus nog backups naar de cloud.
Dit soort reacties en adviezen drijven de bedrijven naar het niet serieus kunnen nemen van de ICT omdat dit niet realistisch is. (kostentechnisch voor de diensten die ze willen)

Er zijn vele oplossingen die je kan doen die kosteneffectiever zijn maar luister als eerste eens naar het bedrijf en maak afspraken over wat ze echt nodig hebben en bereid zijn te betalen. En ga niet een ferrari kopen om boodschappen te doen en dan later klagen dat je geen budget krijgt voor benzine.
Of wat ik ook helaas vaak zie dat het bedrijf maar zelf extern gaat praten omdat de ICT met zulke rare verhalen komen die het alleen maar complex maken. En dan later over de schutting gooien en dan krijg je de reacties die jij nu ook geeft.

[Reactie gewijzigd door COW_Koetje op 22 juli 2024 16:45]

[K-aroq]

Gelukkig, ik ben niet de enige die er zo over denkt. En het laatste wat je zegt is ook zo waar. Hakken in het zand en dan verontwaardigd zijn als er iets komt waar je niet hebt meebeslist. IT-ers zouden gewoon eens veel meer naar het bedrijfsbelang moeten kijken en als dat extern beter bediend wordt daar in mee gaan, en mee praten zodat hun kennis in ieder geval wordt meegenomen in de beslissing.

[TRAXION]

Sowieso ben ik al 10 jaar uit de branche en is er in de tussentijd een hoop veranderd, maar rond 2001/2002 ongeveer weet niet meer precies was het gewoon een puinzooi overal via detachering bij verschillende partijen geweest en het was altijd wel iets.

Of budgetten of de techniek welke nog niet zo ver was, partijen welke gekozen werden vanwege snoepreisjes "ouwe jongens krentenbrood"

Tegenwoordig is de keuze natuurlijk veel groter de markt volwassener geworden en door concurrentie en technische ontwikkelingen veel flexibeler.

[Reactie gewijzigd door TRAXION op 22 juli 2024 16:45]

[Jazco2nd]

Maar je bent het toch wel eens dat er in die tijd veel minder services en systemen gebruikt werden? Een ziekenhuis van nu is gewoon een digitale machine. De kosten om een dergelijke inhouse oplossing op te zetten en te onderhouden lijken mij voor een modern ziekenhuis volstrekt onhaalbaar en ook gek, laat de resources naar patiënten gaan en specialistische partijen de ICT als service verlenen..

[TheDutchChief]

Werk in een regionaal ziekenhuis, bijna alles on premise. Kan best. Maar kan me voorstellen dat je de website en aanmeldpaaltjes uitbesteed en je primaire processen zelf doet.

[kamerplant]

On premise is alleen geen enkele garantie dat er nooit een storing is.

[frankivo]

In tegendeel zelfs.

[Shadow771]

Heb je bij clouds nooit een storing dan...?

nieuws: Microsoft 365 had een storing van meer dan zes uur
nieuws: TransIP Stack-opslagdienst is door twee defecte schijven deel van dat...
nieuws: Storing bij Google Cloud trof diensten als Spotify, Snapchat en Disco...

[K-aroq]

Ik neem aan dat je cijfers hebt waaruit blijkt dat de availability van on-prem veel beter is. En ook graag een vergelijking van de availability bij gelijke kosten.

[tweaknico]

Maar de storing is dan ook alleen in een omgeving niet in een weid verspreide omgeving.

[TheDutchChief]

Daarom ligt er zelfs een complete (geoefende) papieren noodprocedure klaar.

Maar ik reageerde eigenlijk op de stelling dat on premise niet haalbaar zou zijn, dat is niet zo.

[Reactie gewijzigd door TheDutchChief op 22 juli 2024 16:45]

[TRAXION]

ja maar definieer je primaire processen, naar mijn idee moet een ziekenhuis zelfstandig moeten functioneren zodra je de internetaansluiting spreekwoordelijk eruit trekt.

Er is naar mijn idee teveel vertrouwen op verbindingen stel er breekt een oorlog uit en een belangrijk internet knoop punt wordt platgelegd of een terroristische aanslag waarbij verbindingen stuk lopen hoe gaat de zorg dan nog door ?

Ik heb het in dit geval over de extreme uitersten.
Tuurlijk er zijn genoeg mogelijkheden om langs een storing te werken tegenwoordig maar in een echte crisis situatie valt er toch redelijk wat weg ben ik bang.

Overigens zit ik al zeker 10 jaar niet meer in de automatisering dus durf geen definitieve uitspraken te doen.

[Reactie gewijzigd door TRAXION op 22 juli 2024 16:45]

[Jeroenneman]

Ze kunnen toch ook prima zelfstandig functioneren? Het gaat om het patiëntportaal wat extern wordt benaderd.

[K-aroq]

Dan moet je ook een eigen energiecentrale hebben. Nu hebben ziekenhuizen ook slechts een noodstroomvoorziening voor het hoognodige als de elektriciteitsvoorziening uitvalt.

[TRAXION]

Bedoel een bom op een internet knooppunt...

En operaties kunnen ziekenhuizen blijven uitvoeren door backup mogelijkheden.

[TheDutchChief]

Eigen energiecentrale: check!

[TheDutchChief]

"Er is naar mijn idee teveel vertrouwen op verbindingen stel er breekt een oorlog uit en een belangrijk internet knoop punt wordt platgelegd of een terroristische aanslag waarbij verbindingen stuk lopen hoe gaat de zorg dan nog door ?"

Bij ons op het ziekenhuislab staan een map met papieren aanvraag- en uitslagformulieren alsmede een volledig uitgeschreven noodprocedure die getest is in de praktijk (als we toch de servers een keer moeten updaten moet de spoedzorg gewoon door).

[Bitfreakie]

Inderdaad. En dat geldt niet alleen voor de spoedzorg, in het ziekenhuis waar ik voor kort werkte waren allerlei noodvoorzieningen om de patiëntendossiers en -afspraken te kunnen raadplegen in het geval van nood. Veel systemen kunnen ook onafhankelijk van het netwerk draaien en later weer syncen.

[TheDutchChief]

Er is altijd ergens een grens aan capaciteit, de stroomvoorziening heeft een dubbele backup, maar alle meetapparatuur werkt wel op stroom, drie bommen en onze testcapaciteit decimeert. Het hele mondkapjesdebacle van het voorjaar is ook zo iets. Wat ik alleen wil zeggen is dat een ziekenhuis zonder ICT niet stilvalt, zonder getrainde medewerkers wel trouwens. Tijdens oefenen blijken we nog behoorlijk wat overeind te kunnen houden. De uitgestelde zorg door Covid heeft natuurlijk meer van doen doordat patiënten juist niet naar het ziekenhuis (kunnen) komen, niet omdat het ziekenhuis slecht functioneert.

[TRAXION]

Het hele idee van het systeem daar ontwikkeld begon bij de nood voor een geautomatiseerd voorraad systeem met mogelijkheden tot facturatie etc etc dat dit daar begon en eindigde als een systeem tot waar patiënten dossiers stonden.

Maar goed ik kan dit moeilijk onder woorden brengen zonder informatie te noemen welke ik niet wil delen aangezien dit een ex-werkgever is en het niet mijn positie is deze informatie te delen.

[Blokker_1999]

Je bedoelt in de tijd dat elke vorm van x-ray nog ontwikkeld moest worden, in de tijd dat afspraken in een papieren lijst stonden, in de tijd dat dossiers in de kelder bewaard werden?

Vandaag kan je naar het ziekenhuis om je te laten testen en morgen heeft je eigen huisarts de resultaten. Dat kon in die tijd niet. Zorg is geëvolueerd en voor een groot deel is dat een vooruitgang. Maar daar zitten soms ook nieuwe problemen aan. Andere problemen.

[TRAXION]

@Jazco2nd Dit is wat het dijklander ziekenhuis al rond 2000 had met een zelf ontwikkeld pakket.

Als er bij de bali iets werd gedaan worden alle calls voor het traject automatisch uitgevoerd.

En ja in die tijd kwamen de eerste digitale röntgen machines waar een whopping 100tb machine voor geïnstalleerd werd in de tijd bizar veel data voor 1 server.

En ook deze data was direct door een arts te zien door koppeling via de systemen.

Een deel van het ontwikkelteam is opgeslokt door chipsoft en zou mij ook niets verbazen als delen code opgekocht zijn hierbij.

In die tijd werd er echt aan een hoogstaand pakket gewerkt met een goede organisatie en structuur.

En jazeker huisartsen hadden ook direct de resultaten digitaal via een eigen netwerk opgezet vanuit het waterlandziekenhuis.

[Reactie gewijzigd door TRAXION op 22 juli 2024 16:45]

[Navi]

100TB in 2000? dat zijn 2500 disks van 40GB, los van eventueel RAID. Weet je dat zeker?

[satya]

Zou best kunnen, fofo's werden op een gegeven moment ook digitaal opgeslagen, en werden in het begin nog met toen nog speciale hoge resolutie schermen bekeken die onder andere door Barco geleverd werden, in die tijd eens bij de club in Belgie langs geweest.

[TRAXION]

Kan ook 10tb zijn geweest waren 2 volle racks naast elkaar als ik het me goed herinner het was iig een gigantische opslag.

Ikzelf deed niet veel kwa storage systemen maar weet wel dat ik zeer onder de indruk was destijds zou ook kunnen dat die server iets later geplaatst is 2001/2002 maar iig voor 2003 toen haalde ik namelijk mijn rijbewijs en dat was net voordat ik opstapte de detachering in.

Keek net even naar de disks grootte waarschijnlijk zal dit later zijn geweest.

Maar goed het verhaal over rontgen foto's lag niet bij de automatisering maar de techniek van de rontgen machines.

[Reactie gewijzigd door TRAXION op 22 juli 2024 16:45]

[Cergorach]

In 2002 waren er 120GB schijven beschikbaar, waarmee je prima in twee volle racks op de 100TB kan komen. Vergeet ook niet dat het internet van toen een hele andere aangelegenheid was dan nu. En dan hebben we het over bandbreedte up en down, kosten, beschikbaarheid, etc. Google was slechts een paar jaar actief, er was nog geen 3G beschikbaar, er waren amper smartphones, laptops waren van het type 'brick', Windows XP kwam net uit, etc.

Dat als de reden aandragen waarom cloud een slecht idee is, is natuurlijk van de zotte. Het issue is niet dat cloud ansich beter is dan selfhosted, maar het is nu eenmaal niet de corebusiness van een ziekenhuis (en menig andere bedrijven). Verwachten dat elk bedrijf dat het wel hun corebusiness maakt ook direct kwaliteit levert laat blijken dat er weinig ervaring is op dat vlak. Net als in iedere branch zijn er zat prutsers te vinden met mooie marketing/contracten, maar in de praktijk alleen maar leid tot extra kosten. De kunst is niet een goede cloudprovider te zijn, de kunst is de juiste IT provider er uit te kunnen pikken en daar gaat het vaak mis, dergelijke bedrijven hebben intern niet de kennis/kunde om daar een echt goede beslissing over te maken. Met externen werken kan goed helpen op dat vlak , maar daar moet je ook weer kwaliteit er uit weten te vissen.

Er is een hoop gezeik over MS, Amazon, etc. Maar dat zijn wel bedrijven die extreem veel ervaring en kennis hebben opgedaan op dit vlak en effectief maar een habbekrats vragen om zo een omgeving te leveren. Zijn er dan geen issues met dergelijke oplossingen? Natuurlijk wel, maar voor het gros van de bedrijven is het een veel betere oplossing dan wat anders. Ziekenhuizen zijn juist van het type waarbij bepaalde systemen ook lokaal moeten draaien omdat die daar belangrijk genoeg voor zijn. Echter moet alles toch met elkaar communiceren en kunnen grote delen prima in de cloud draaien, echter niet alles. En volgens mij gebeurt dat ook niet.

[TRAXION]

Bedankt voor je post ! Dit verwoord denk ik wel ongeveer zoals ik erover denk.

Ikzelf ben het vak uitgestapt om andere ambities te volgen, er is natuurlijk een hoop veranderd in de afgelopen decennia.
Daarintegen ben ik van mening dat je core business "zorg bieden" ondersteund moet worden door it oplossingen welke gewoon blijven functioneren zolang er stroom in het pand is.

Zelfs iets stoms als een informatie paal aansturen lijkt me vrij simpel intern aan te sturen ik krijg altijd het idee dat dit soort partijen een bepaalde controle willen houden zodat de klant niet kan overstappen van aanbieder.
Voelt voor mij aan als vendorlocking.


Kan je bij deze cloud partijen tegenwoordig niet een mini cloud in home krijgen?

[Reactie gewijzigd door TRAXION op 22 juli 2024 16:45]

[Cergorach]

Kan je bij deze cloud partijen tegenwoordig niet een mini cloud in home krijgen?

Dat kan op verschillende manieren. Van een container vol computer servers die geplaatst wordt naast het pand tot iets als Azure Stack. Maar het kan ook zo simpel als een goede VPN tussen je lokale en je cloud omgeving. Ligt er geheel aan wat het moet kunnen en wat het beschikbare budget is.

Je zal ook per systeem moeten kijken naar de functie, voor verschillende ziekenhuis zaken heb je gewoon de informatie nodig op locatie. Maar bv. je Exchange servers niet. Voor een administratie kantoor kan je beter het administratie pakket in de cloud hangen, want dat heb je niet perse op locatie nodig en kan je prima benaderen vanuit huis of een ander kantoor/locatie. Maar bv. staalbewerkingsbedrijf ga je de server die dergelijke machines aanstuurt niet in de cloud zetten...

[TRAXION]

Helaas gaat vpn uiteindelijk ook weer langs een knooppunt tenzij je echt hele hoge kosten gaat maken, maar een mini cloud/proxy/copy etc inpandig en deze synchroniseren met een externe server zou in mijn ogen dan bij bepaalde handelingen beter lijken.

Maar goed ik haal dan ook scenario's aan welke een hele kleine kans hebben, helaas is een 0,01% kans al teveel als je het over een cruciaal onderdeel hebt als zorg.

Dan heb ik liever dat ze eens gaan schoppen tegen die medicijn fabrikanten en andere partijen die de zorgkassen leegtrekken ipv keuzes te moeten maken omdat je moet concurren met andere ziekenhuizen.

Ik snap het idee achter marktwerking maar kan daar gewoon niet bij met mijn gedachte maar goed daarom ben ik andere ambities gaan volgen.

[Blokker_1999]

Een probleem is natuurlijk dat intern functioneren ook al lang niet meer zo eenvoudig is daar intern vandaag niet meer betekend "in het zelfde gebouw". Zorg instellingen zitten vandaag in samenwerkingsverbanden of hebben zelf meerdere locaties. Gewoon al een centraal afsprakenregister intern houden betekend dus dat deze alsnog via het internet (en dat kan de cloud zijn, dat kan MPLS zijn, dat kan VPN zijn, ...) bereikbaar moeten zijn door de verschillende sites.

[TRAXION]

In die tijd had je ook al zelfstandige artsen/praktijken welke intern zaten en toch gebruik maakten van het systeem, ik heb niets tegen een cloud oid.

Maar volledig op de cloud vertrouwen is in mijn opinie niet handig, nou was ik gisteren niet al te scherp na wat tegenslag, en ben ik voordat cloud hip werd de branche uitgegaan.

In mijn visie zou je prima een grote krachtige cloud kunnen gebruiken met veel voordelen en daarnaast een redundant mini cloudje neerzetten inpandig zodat bij eventuele calamiteiten je in ieder geval lokaal 100% van je mogelijkheden houdt.
Weliswaar kan het geen piekbelasting aan.
En uiteraard snap ik dat er een kostenplaatje aanhangt maar je kan ook grote delen wegstrepen in een minicloud welke je in de offsite lokatie wel kan benutten.

Maar dat zeg ik ben al weer wat jaartjes er uit maar ken me de citrix en Oracle omgevingen nog herinneren waarbij behoorlijke groepen gebruikers half werkloos waren omdat er 1 verbinding uitpiepte.

[proatjeboksem]

destijds (opa vertelt) ging het veelal op tape, of MOD https://en.wikipedia.org/wiki/Magneto-optical_drive (Magnetisch-Optical Disk)

En idd, in ziekenhuizen geweest met rekkenvol opslagdevices, DVD torens, etc.
Maar ook in kliniekjes met gewoon CD's in hangmappen. Maar toen was bv. een CT onderzoek nog geen gigabytes groot, zoals nu.

[tweaknico]

De Archive.org site had rond die tijd ook al een peta byte box in een full size rack.
maar dat was met zeer dedicated hardware.

[TRAXION]

Dit was ook geen zelfbouw baksel hoor kwam netjes verscheept in wooden crates en was toendertijd state of the art, maar goed als je de kosten van een digitaal rontgen apparaat bekijkt zal zo een server ook maar een druppel op een gloeiende plaat zijn.

[tweaknico]

Met dedicated hardware bedoel ik in de archive.org case dat gekeken was naar warmte productie, en voldoende compute capaciteit naast alleen maar storage. Archive.org moet ook data (= het hele internet voor zover leesbaar) indexeren etc.

[kevinwalter]

Heerlijk dat wijzen van vingers voordat er duidelijkheid is.. In plaats van dat ze samen gaan kijken naar een oplossing, daar kan je tenminste wat mee.

[The Realone]

Denk je echt dat ze nu niet met man en macht bezig zijn?

In een ideale wereld is meteen duidelijk wat er aan de hand is en wie er exact verantwoordelijk is, vervolgens brengen we dat op minuut 1 naar buiten.

Nu, in de echte wereld gaat iets plat en wordt dit direct opgepikt door de media voordat er ook maar duidelijkheid is bij de partijen. Vervolgens worden die platgebeld met vragen "WIE? WAT? WAAR? HOE? WANNEER?". Tja, dan krijg je wel eens dit soort dingen. Het boeit toch ook helemaal niet dat wij, als buitenstaanders, vanaf minuut 0 weten wie waar mee bezig is? Het gaat erom dat het efficient en snel opgelost wordt.

[kevinwalter]

Als ik de reactie zo lees niet. Het is onprofessioneel om gelijk vingertje te wijzen voordat er duidelijkheid is.

[The Realone]

Dat is hoe jij het leest en het is ook nog eens in een zeer beknopte versie van de NOS. Maar als ik thuis geen internet heb en ik bevestigd heb dat het niet aan mij ligt, wijs ik naar mijn ISP want die is, vanuit mijn perspectief, verantwoordelijk voor de verbinding. Als het probleem vervolgens bij een achterliggende transit provider blijkt te zitten zal mijn ISP ook zeggen dat het probleem niet bij hun zit. Dat heeft niks te maken met het probleem afschuiven, maar de verantwoordelijkheid aanwijzen vanuit verschillende perspectieven.

Wat de media (dus ook Tweakers) ook kan doen is dit niet opnemen in hun nieuwsbericht, want zolang er nog geen duidelijkheid is gegeven voegt het niks toe en krijg je dus dit soort reacties op nieuwsberichten. Vertel dan gewoon "er is een storing, er wordt aan gewerkt en het is vooralsnog niet duidelijk waar het probleem zit". Update het bericht dan later, of plaats een nieuw bericht wanneer er duidelijkheid is.

[kevinwalter]

En exact dat bedoel ik. Maar dat zou eigenlijk vanuit NWZ al zo moeten zijn.

Assumption is the mother of all fuck-ups.

[Dorank]

Het is de klant die met de vinger wijst, dat is helaas gewoon de standaard, ze hebben immers niemand anders om naar te wijzen.

[souljah1h]

Als het aan de gebruikers ligt is alles een prio 1

[Plopeye]

Zeer zeker waar, en ze zijn nog kwaad ook als de servicedesk aan de hand van de prio definitie terugzet naar een lagere prio.

[Technomania]

Ik dacht dat die aanmeldzuilen gewoon via een intern netwerk gingen. Ik zie behalve updates krijgen verder geen nut dat die dingen met het internet verbonden zijn.

[r03n_d]

Als de EPD-software niet te benaderen is kan je én niet in de dossiers, én niet bij de afspraken. Dan kan je dus ook niet aanmelden. Dat klinkt mij als de meest logische uitleg.

[Technomania]

Maar dat kan toch op een andere server staan. Aanmeldzuil-->Server met EPD-->Internet

[Intrepidity]

Sure, maar als je server met EPD dan niet werkt is je aanmeldzuil ook niet functioneel.

[Mardox]

In dit geval doet de EPD software het echter wel. Dus in het ziekenhuis kan men wel gewoon in de dossiers en afspraken. Sommige ziekenhuizen hebben aanmeldzuilen die andere software dan die van HiX gebruiken, dan worden de o.a. afspraken dus ook daarheen gestuurd.

[DialOut]

De zuilen van Chipsoft draaien als webapplicatie en blijkbaar hosten deze ziekenhuizen het elders.
Deze storing heeft niet met andere software leveranciers te maken.

[r03n_d]

Ah oké, maar zo staat het niet in het bericht hierboven.

Door de storing zijn dossiers niet in te zien en werken aanmeldzuilen in de ziekenhuizen niet.

[eric.1]

Ik weet eerlijk gezegd niet hoe die zuilen werken, maar deze zullen gok ik ook gewoon van een portaal-functie gebruik maken. Dit zegt niet dat dit via het reguliere internet loopt, het kan best via hun eigen fiber naar een DC lopen (waardoor het nooit hun "private-cloud" verlaat).

En als die portaal in het DC een probleem heeft, dan zullen die zuilen daar ook last van hebben.

[Kman]

Misschien toevallig, maar kan t te maken hebben met een tls deprecation in elastic cloud die vandaag is doorgevoerd? Zie https://cloud-status.elastic.co/ en https://www.elastic.co/bl...-to-elasticsearch-service

[Reactie gewijzigd door Kman op 22 juli 2024 16:45]

[BushWhacker]

Als dat het geval is hebben ze pas een paar jaar de tijd gehad om een juiste TLS versie te implementeren. Da's wel heel weinig.

[Reactie gewijzigd door BushWhacker op 22 juli 2024 16:45]

[FreezeXJ]

Kom op, je gaat toch pas wat wijzigen als de volgende update het echt verwijdert? Beetje werk vooraf doen, heb je tijd over of zo?

(nee, niet ideaal, maar wel te vaak de realiteit. Zo lang management nog meer belooft dan devs waar kunnen maken is het vechten om technische issues op te lossen)

[WhizzCat]

Waarschijnlijk niet. ChipSoft gebruikt hun eigen datawarehouse-achtige systemen. Voor zover ik weet (ben er ondertussen al een jaartje tussen uit) doen die niks met Elastic enzo.

Het is aannemelijk, gezien al de reacties, dat er iets met een stuk routing, fibers, IX'en of dat soort dingen iets hopeloos mis gaat. Als netwerkbeheerder ben ik natuurlijk geneigd om te zeggen dat dit niet aan het netwerk ligt, maar met 15 jaar zorg ICT achter de kiezen doet mij vermoeden dat het nu wel een netwerk probleem is. Klapperende routers enzovoorts.

Ik las ergens al een reactie dat iemand soms wel/soms niet kon inloggen, dus het lijkt mij zo'n soort probleem. Lastig te tackelen, dat dan weer wel.

[fantafriday]

Hoop dat de ICTZ server waar nu.nl over spreekt niet in AS212922 van ictz hosting services b.v. zit. Die heeft maar één provider namelijk.

[Reactie gewijzigd door fantafriday op 22 juli 2024 16:45]

[bazzi]

Dat is niet echt hoe het hoort nee...

[JorisVanHoute]

Kan het niet laten....... Hebben ze misschien last van een virus?

[Bozebeer38]

Ransomware?

[Anoniem: 1420638]

Laten we hopen van niet, ziekenhuizen moeten met rust gelaten worden. Vooral in deze tijden

[Reactie gewijzigd door Anoniem: 1420638 op 22 juli 2024 16:45]

[Eonfge]

Juist makkelijke, vette, doelwitten. Veel tech-illiteraire mensen, weinig financiering voor IT, grote maatschappelijke druk om zo snel mogelijk weer operationeel te zijn.

Als ik even op BBC kijk, zie ik dat er jaarlijks ransomware attacks zijn p ziekenhuizen. DIt zou hoogstens de eerste keer in Nederland zijn.

[Reactie gewijzigd door Eonfge op 22 juli 2024 16:45]

[TheVivaldi]

De eerste keer in Nederland?
https://www.nu.nl/algemee...teerd-met-ransomware.html

[Eonfge]

Waaah, die stond dus niet op de BBC site

[R34P3R4LF3]

Je kunt het ook van de andere kant zien, ziekenhuizen zijn "booming business" rond deze tijd en worden vooral nu aangevallen.

Hoop ook van niet natuurlijk...

[Scriptkid]

meeste groupering hebben aangegeven in deze tijd die juist met rust te laten maar kan natuurlijk altijd een mail verkeerd gelezeen worden , maar dan zouden ze meteen de decryptie keys geven.

of ze hun woord houden is natuurlijk iets anders.

[Poekie McPurrr]

Geld is geld.

[Scriptkid]

verschil is wel de bullseye die je op je rug paint,

[ToolBee]

Of gewoon de "Russen"...
Maar op 3 lokaties, zeer ver van elkaar. En ertussen geen last is niet "iets bij de provider".

[satya]

Vraag ik mij ook af aangezien er nu een issue is in veel ziekenhuizen in de VS met een uitwaaier naar de UK.

[Robinski]

Heb via via het gerucht gehoord dat het om een DDoS zou gaan.

[ToolBee]

Dat zeg je voor een vriend?

[Rudie_V]

Onbekende oorzaak...ojee, ransomware? Hopelijk niet.