Huisartsen gedwongen tot gebruik uiterst onveilige Java-versie

Veel huisartsen gebruiken al sinds april gedwongen een onveilige Java-versie. Ze kunnen niet updaten, omdat ze dan niet meer kunnen inloggen op het systeem waarmee ze hun patiëntdossiers beheren. Volgens de softwareleverancier gaat het om 'honderden' huisartsen.

De huisartsen wordt al sinds halverwege april met klem geadviseerd om update 21 van Java 7, de meest recente Java-versie, niet te installeren, omdat het inloggen met de Uzi-pas dan niet meer werkt. Dat blijkt uit een interne nieuwspagina van Promedico, een webapplicatie die door huisartsen wordt gebruikt om patiëntendossiers te beheren. De Uzi-pas is een door de overheid uitgerolde pas die kan worden gebruikt door onder meer zorgverleners om zichzelf te identificeren.

Doordat de huisartsen niet kunnen updaten naar de nieuwste Java-versie, zijn ze kwetsbaar voor de beveiligingsproblemen in de voorgaande versie van Java. Die versie bevatte 42 beveiligingsproblemen die met de nieuwe update zijn opgelost. Van die bugs zijn er maar liefst 39 op afstand te misbruiken, en enkele van de problemen zijn geclassificeerd als 'kritiek'. Oracle adviseert gebruikers om de patch zo snel mogelijk uit te rollen, vanwege de ernst van de opgeloste beveiligingsproblemen.

Directeur Pita van Arkel van Promedico erkent dat huisartsen wordt geadviseerd om hun Java-versie niet te updaten, maar relativeert de ernst van de zaak. Van Arkel benadrukt dat veel huisartsen niet inloggen met de Uzi-pas, maar met een eigen pas van Promedico. Het aantal huisartsen dat wel met een Uzi-pas inlogt en niet kan updaten, schat ze op een 'paar honderd'. "We adviseren die klanten om tijdelijk even geen update te doen", aldus Van Arkel. "In de loop van deze week zullen we onze software aanpassen", zegt ze. Onduidelijk is waarom het updaten van de website anderhalve maand moest duren, en waardoor de incompatibiliteit met de update werd veroorzaakt.

Volgens Van Arkel is het systeem van Promedico 'sterk beveiligd'. Daarmee gaat ze voorbij aan het feit dat ook andere websites een beveiligingsprobleem kunnen vormen. Kwetsbaarheden in Java behoren tot de meest misbruikte bugs, bleek eerder uit onderzoek van Kaspersky. Door bijvoorbeeld een advertentienetwerk te infiltreren en het te gebruiken om een exploit-kit te serveren, kunnen kwaadwillenden middels een bug in Java inloggen. In het verleden hebben meerdere grote websites, waaronder bijvoorbeeld De Telegraaf en NU.nl, malware geserveerd.

Reacties (151)

Hetzelfde geldt voor de zakelijke rabobank software. https://www.rabobank.com/...stallatie_handleiding.pdf

wij hebben hetzelfde geintje met deutsche bank.
onze financiële afdeling gelooft gewoon niet dat banken dit eisen. wij systeem beheer worden met een scheef oog aangekeken omdat we de onveiligheid aankaarten.

zucht

@zovty
Bij de Rabo Cash Management (zoals de zakelijke rabo software heet) hoef je geen gebruik te maken van een Java-upload applet bij het importeren.
Je kan ook voor "gewoon" SSL kiezen. Dan werkt Java 7u21 wel gewoon.

Directeur Pita van Arkel van Promedico erkent dat huisartsen wordt geadviseerd om hun Java-versie niet te updaten, maar relativeert de ernst van de zaak. Van Arkel benadrukt dat veel huisartsen niet inloggen met de Uzi-pas, maar met een eigen pas van Promedico. Het aantal huisartsen dat wel met een Uzi-pas inloggen en niet kan updaten, schat ze op een 'paar honderd'.

Laat een huisarts nou veelal zo'n 3000 patiënten hebben. Dus enkele honderdduizenden (mogelijk nabij een miljoen) persoonsgegevens en een bijbehorende medische dossiers welke onvoldoende beschermd worden. Relativeer dat eens.

[Reactie gewijzigd door mbarie op 3 juni 2013 13:36]

Ok, dan zal ik het toch maar eens relativeren, aangezien niemand dat doet.

1. Bij dit soort beveiligings issues, wordt altijd direct de leverancier aangevallen, nooit de crimineel die inbreekt. Dat lijkt me toch een beetje de omgedraaide wereld. Boud gezegd, maar denk er maar eens over na.
2. Software ontwikkelen kost geld. Geld is geen oneindige resource. Het heeft geen zin een kluis van 1 miljoen euro te bouwen om 1 cent te beveiligen. Ga die diskussie maar eens aan.
3. De UZI pas wordt alleen in nederland gebruikt. Ga maar eens zoeken naar "open source" resources om met dat ding te communiceren.

[Reactie gewijzigd door ijmert op 3 juni 2013 16:36]

Jij werkt bij Promedico, wordt dit intern ook zo gerelativeerd?

1. De crimineel is fout en strafbaar, maar de leverancier is naïef en nalatig. De niet ter zake kundige huisarts en zijn patiënten zijn uiteindelijk de dupe van jullie advies.
2. Het gaat niet om 1 cent maar om medische gegevens en om het kunnen voorschrijven van recepten.
3. Je hoeft die UZI-pas toch niet te ondersteunen? Cdwave gaf een technisch veel mooiere oplossing.

Ik heb het idee dat er bij Promedico de verkeerde mensen zijn aangenomen of dat er verkeerde keuzes gemaakt worden. Niet alleen dit beveiligingsprobleem maar ook andere dingen. Het menu in Promedico dat opent als je je muis over die grote ronde apenstaart beweegt, kost meer dan een megabyte aan Javascript-code. Om brieven efficiënt vanuit Promedico te digitaliseren moet je Windows XP draaien (in Win8 moet je scannen naar een bestand en dat bestand uploaden). Er worden drie verschillende AJAX-libraries door elkaar gebruikt. Dat is toch ook allemaal knullig?

Punt 3 is niet correct. Je moet de UZI pas wel ondersteunen voor communicatie met het LSP, met het certificaat dat op de UZI pas staat moeten berichten digitaal ondertekend worden. Je moet daarvoor bij het private key certificaat op de pas kunnen, een https client certifcaat gebruiken (wat cdwave voorsteld als ik het goed begrijp) is dan niet afdoende.

De UZI pas wordt alleen in nederland gebruikt. Ga maar eens zoeken naar "open source" resources om met dat ding te communiceren.

De UZI pas is een standaard smartcard die werkt met standaard readers en software.

Het is wel opmerkelijk dat juist een systeem wat bedoeld is om 'strong authentication' toe te voegen, het geheel weer zwakker maakt. Ik ben bang dat we komende tijd veel vaker van dit soort berichten gaan tegenkomen. De UZI-pas, en wat dat betreft ook de Rijkspas, is een heel goed middel maar wordt (nog) amper gebruikt waarvoor het eigenlijk bedoeld is: echte strong multi-factor authentication. Je ziet echter nu vanuit de overheid (en in geval UZI pas ook de markt) veel meer druk om daadwerkelijk hiervan gebruik te gaan maken.

Nu wil de rijksoverheid ook de eINK gaan implementeren, dus feitelijk hetzelfde maar dan voor burgers. Ik ben erg benieuwd hoe dat gaat verlopen! Sidenote: heel recentelijk voor het eerst een iPad toepassing gezien die in combinatie werkt met de Rijkspas (en dus ook UZIPas) - maar dan uiteraard wel met een aparte sleeve die pas (en ook vingerafdruk) mogelijk maakt op iPad.

[Reactie gewijzigd door MartijnDutch op 3 juni 2013 13:22]

Het probleem is dat feitelijk weinig His leverantiers zich aan wetgeving houden als het op privacy aan komt.

Bij wet is het verplicht om data beveiligd op te slaan tenzij er onredelijke investeringen tegenover staan.

Dus wat gebeurt er in de praktijk.

Onbeveiligde protocollen (ftp, telnet, http) via een 'afgesloten' netwerk dat ezorg heet.

Onveilige java versies (mee) leveren, want dat is getest.

Alle data in dezelfde database, dus geen scheiding tussen de verschillende praktijken, want dat is lekker eenvoudig en via een sql query (select <bla> where praktijk=mij_praktijk and <meer bla>)

Verder beveiligen we die servers natuurlijk niet meer met wat standaard username / password combi's en al helemaal geen updates. Dat betekend alleen maar onzekerheid voor (java) ontwikkelaars, want het platform veranderd telkens en dan zijn er geen garanties op correcte werking. Veilige protocollen zoals https / sftp, ftps etc zijn alleen maar lastig, dan moet je wat met certificaten doen. (ok promedico asp is vanuit client -> server wel https, maar dat is slechts 1 van de mogelijk hissen)

Wachtwoorden voor toegang worden onbeveiligd in installatie directories achter gelaten, danwel hard coded in (java) code opgenomen.

etc. etc.

Dus het feit dat een java update niet geinstalleerd 'mag' worden is slechts een topje van het werkelijke probleem.
Verder is de uzi pas ook als is op het op open standaarden gebaseed, krom geimplementeerd. Wil een arst het b.v. gebruiken om email van encryptie / signatures te voorzien, dan moet outlook zo ingesteld worden dat ca's worden genegeerd.
Verder werkt de uzi pas alleen maar samen met 1 stuks middle ware, want alle anderen die zich aan de standaarden houden snappen niets van het feit dat er 3 certificaten op 1 java card zitten met alle 3 een ander (administratief) doel.

LSP / AORTA is ook een mooi voorbeeld. Laten we hier als Nederland voor een internationale standaard kiezen (HL7v3), maar er wel een Nederlands sausje overheen gooien, zodat alle beschikbare tooling niet meer werkt, maar dat er specifieke Nederlandse tooling gemaakt moet worden.
Is natuurlijk ideaal voor werkverschaffing, maar zonde van de impact die het heeft. Tooling is dus minder goed getest. open source pakketten werken niet, zonder de nodige aanpassingen (en his leverantiers zijn vooral open source gebruiker ipv provider)

Open standaarden met b.v. standaard pki systemen zoals gpg/pgp waarbij de huisarts / apotheker zelf echt in control van zijn / haar data is worden niet toegepast. Terwijl die systemen er al jaaren zijn en bewezen werken. Encryptie door de huisarts is n.l. niet echt gewenst, want dan kan de data niet meer verkocht worden aan onderzoeks instanties e.d. dus is er minder geld te verdienen

(en daarmee is de circel weer rond, want dan kan je beargumenteren dat veilig opslaan van data enorme kosten met zich mee neemt en dat je het daarom niet hoeft te doen, terwijl je je dan nog steeds aan de wet houd)

Dit is exact waarom ik weiger om mee te doen aan het EPD. OverheidGevoelige informatie en ICT gaan niet altijd samen, hier blijkt maar weer dat men beveiliging niet serieus genoeg neemt. Het zijn dan maar enkele honderden (!) huisartsen, maar die zijn in theorie dus allemaal vrij gemakkelijk te hacken.

[Reactie gewijzigd door dubbeldekkert op 3 juni 2013 13:36]

Dit is exact waarom ik weiger om mee te doen aan het EPD. OverheidGevoelige informatie en ICT gaan niet altijd samen, hier blijkt maar weer dat men beveiliging niet serieus genoeg neemt. Het zijn dan maar enkele honderden (!) huisartsen, maar die zijn in theorie dus allemaal vrij gemakkelijk te hacken.

Helaas helpt dat niet. De huisarts heeft natuurlijk wel lokaal een dossier over jou en als jouw huisarts met een verouderde java versie werkt, ligt de pc open, niet zozeer de verbinding met het EDP.
Kortom, alle info die zich op de pc bevindt zou op straat kunnen komen te liggen.

als jouw huisarts met een verouderde java versie werkt, ligt de pc open

Bullshit.

De vulnerabilities in Java zijn alleen te misbruiken als je standaard alles wat Java of een Java applet is laat uitvoeren.
De simpele oplossing voor de security is om op de computer waar een huisarts zijn administratie op doet het uitvoeren van plugins in de browser standaard uit te schakelen. En door er geen random applicaties op te installeren.

Doodeenvoudig.

P.S. Als je je zorgen maakt over de kwetsbaarheid van Java, dan raad ik je aan om bovenstaande security tips ook op te volgen. Bonus: random flash crap wordt ook pas actief als je er om vraagt.

De simpele oplossing voor de security is om op de computer waar een huisarts zijn administratie op doet het uitvoeren van plugins in de browser standaard uit te schakelen. En door er geen random applicaties op te installeren.

Doodeenvoudig.

Goed idee, inderdaad doodeenvoudig. Alleen jammer dat de huisarts nou net een java plugin nodig heeft omdat we het hier over een web-applicatie hebben.
En ga er maar van uit dat dit op dezelfde pc gebeurt als waarop de administratie draait.

Wat volgens mij beter zou helpen is als browsers plugins standaard niet meer uitvoeren, tenzij een domein op een whitelist staat voor die specifieke plugin.
Vervolgens een popup met "site <site.xxx> wil een java applikatie starten, mag dat ? met de keuzes "Nooit voor <site.xxx>", "Nee", "Ja", "Ja, altijd voor <site.xxx>"

Dat zou het voor mensen die gedwongen worden crappy plugins te draaien een stuk makkelijker maken.

[Reactie gewijzigd door locke960 op 3 juni 2013 16:17]

Goed idee, inderdaad doodeenvoudig. Alleen jammer dat de huisarts nou net een java plugin nodig heeft omdat we het hier over een web-applicatie hebben.

Dan whitelist je die website toch? Kan al tijden.

Ik ben het trouwens wel met je eens dat browser plugins standaard meer opt-in moeten worden.

Alleen jammer dat de huisarts nou net een java plugin nodig heeft omdat we het hier over een web-applicatie hebben.

Plus dat plugins doorgaans standaard geactiveerd woren.

Nieuwe PC uit de doos, en meteen bij de eerste boot staat Flash en Acrobat Reader voorgeinstalleerd en de plugins geactiveerd. Nu weet ik hoe het uit te zetten, maar 99% van de wereldbevolking niet.

Promedico beheerd juist alle dossiers. Er staat helemaal niets bij de huisarts tenzij hij een dubble boekhouding er naast houd.

Dus ja als de UZI pas wordt gebruikt ipv de eigen Promedico pas ja dan ben je onveilig bezig. en heb je een kleine kans dat je gegevens op straat komen. De kans is klein maar hij is er wel.

Daarnaast weet de helft van de huisartsen niet of ze nou een UZI pas gebruiken of een promedico pas. Dus de meeste die ook totaal geen affiniteit hebben met IT zullen hun PC niet van een update voorzien. Of stel meerdere huisartsen op 1 post. Maar 1 van de 20 heeft nog een UZI pas zullen de andere 19 ook niet van updates worden voorzien. Dus ja ik denk dat de kans groot is dat er meerdere geen update hebben geïnstalleerd.

BTW: Promedico heb er vorig jaar een sollicitatie gesprek gehad 2x.. maar na paar maanden geen bericht kreeg ik de recruiter weer eens aan de lijn die nog wel een andere baan had. Na navragen wat er gebeurd was. Bleek dat ze me graag in dienst hadden willen hebben Klikte goed met het team enz.. Alleen neefje van de directrice had ook een IT opleiding en kwam net van school.. Die mag daar nu voor het kantoor zelf als bij bepaalde huisartsen de IT regelen

Vorig jaar werkte er een directeur bij Promedico, de directrice is hier pas vanaf januari in dienst. Voor zover ik weet werken hier geen neefjes van...

Ik weet dus niet waar dit verhaal vandaan komt.

NB. Ik werk dus bij Promedico.

Haha, way to go Ijmert

Dat komt bij iSense vandaan waar ik via een sollicitatie gesprek heb gehad.. Dus ja niet direct bij Promedico vandaan ;-)

Er was een neefje, vriendje of iets dergelijks dat ook voor dezelfde functie als waar ik voor solliciteerde

Dit is exact waarom ik weiger om mee te doen aan het EPD. OverheidGevoelige informatie en ICT gaan niet altijd samen, hier blijkt maar weer dat men beveiliging niet serieus genoeg neemt. Het zijn dan maar enkele honderden (!) huisartsen, maar die zijn in theorie dus allemaal vrij gemakkelijk te hacken.

Dit heeft dan ook helemaal niets te maken met het landelijk schakelpunt, wat in de volksmond het EPD wordt genoemd, maar puur om de eigen administratie van artsen. En ja, die kan heel goed digitaal zijn, ook als jij hebt aangegeven dat je niet wil dat je gegevens met anderen gedeeld worden.

Je comment maakt eigenlijk in 1 keer duidelijk wat er mis is met de huidige naamvoering: EPD = reguliere term voor een entry in een patienten management systeem van een ziekenhuis of huisarts. Ieder ziekenhuis of huisarts heeft zijn eigen EPD management systeem. Het idee was om deze allemaal aan elkaar te knop, om zo de uitwisseling van Elektronische Patienten Dossiers tussen zorgverleners te vereenvoudigen. In plaats van de echte naam LSP, is er toen gekozen (door de media) om dit EPD te noemen. Erg verwarrend, want mensen hebben nu geen flauw idee meer wat er met EPD bedoeld wordt.

Gelukkig wordt het EPD niet (meer) door de overheid ontwikkeld

Een privé bedrijf = nog erger, wie garandeerd dat onze info achter slot en grendel zit (met een deftige muur/dak/vloer er rond)

Geen overheid, en geen privé bedrijf? Dan blijft er nog maar weinig over...

Community? Open Source? Moet vast wel iets mogelijk zijn!

evt publiek-private samenwerking voor het beste van beide kanten...

Ik zie hier trouwens dat ze een Chromebook gebruiken, gaan er dan allemaal patientgegevens in de Google Drive? Ik hoop van niet...

Er staat dat ze de Chromebook meenemen naar patienten thuis, zouden ze de patient-wifi gebruiken of 3G?

[Reactie gewijzigd door Eloy op 3 juni 2013 14:04]

patenten wifi of 3g of zelfs via rooksignalen maakt geen zak uit, zolang de datatransmissie maar goed versleuteld is via een degelijke vpn ...

leuk dat je weet dat huisarts x data naar server y stuurt maar zolang je die inhoud van die data niet weet maakt dat weinig uit...

nu ze echter allemaal een afthanse java versie moeten gebruiken is het wel heel makkelijk om bijv keyloggers te instaleren.

maar honderd artsen? dat moet dus om potentieel tienduizenden patienten dosiers gaan. die vent dit dit durft te relatieveren zou aan mijn scrotum aan de hoogste boom moeten hangen.

het doet je je al direct afvragen welke java versie er bij JOUW huisarts gebruikt wordt, nu is er over mij behalve een rottig hoestje gelukkig niet zo veel bekend ... maar je zult maar wat vaker bepaalde ziektes hebben

Sorry hoor, maar wat een kletskoek! Ga eens wat blogs van securiyty experts lezen, of lees dit: http://arstechnica.com/se...-out-of-your-passwords/3/ en je snapt dat het niet zozeer een kwestie is van óf, maar van wanneer!

Elke beveiliging is te kraken, de kwestie is alleen of je beveiliging het lang genoeg volhoudt zodat het in de praktijk niet haalbaar is. Met enige tienduizenden zorgverleners en locaties) die allemaal toegang hebben (en bijbehorende slechte wachtwoorden) is het dus een gegeven dat het makkelijk is. (Dit overigens náást de kwestie van social engineering waar je in dit verhaal: http://arstechnica.com/te...story-of-the-hbgary-hack/ kunt lezen hoe zelfs experts er in kunnen stinken. )

Allemaal losse systeempjes zijn (hopelijk) niet interessant genoeg maar 1 gecentraliseerd systeem is natuurlijk een leuk target. Dáárom is een landelijk EPD een slecht plan. Het is én een "prime target" én uit de aard der zaak beroerd beveiligbaar. Daar kunnen allerlei technische maatregelen weinig aan veranderen, en daarom zijn allerlei 'technische experts' die beweren dat het wél kan óf mensen met oogkleppen óf leugenaars.

Aanvullend is een nog groter gevaar, misbruik door bevoegden.

In de meeste discussies omtrend EPD ging het altijd om beveiliging tegen hackers en andere onbevoegden. Er werken echter enkele honderdduizenden in Nederland in de zorg als je alle indirecte functies meeneemt.

Waar ik me daarom veel meer druk om maak is een bevoegd persoon die in een dossier kijkt waar die persoon niet in mag kijken. In theorie wordt dat mooi gelogd, maar is er ook naleving?

=> Hoe wordt gecontroleerd of er een behandelrelatie is?

Enkel reactief bij klachten? Probleem is echter dat in veel gevallen dat moeilijk te ontdekken is. Plus dat voor de BN'er in het ziekenhuis waar de gegevens op de Achterklap pagina van de Telegraaf staan, dat te laat is. En voor die burger wiens verzekering op mysterieuze wijze afgewezen is gewoonweg niet te bewijzen is.

Nu kun je het nooit 100% afdekken, maar een systeem waar de persoon zélf kan zien wie zijn/haar gegevens inziet zou al heel wat zijn.

Dat kun je dan aanvullen met een straf voor mensen die of bewust over de schreef gaan, of wellicht herhaaldelijk zeer slordig.

=> Wat is de straf als een arts of verpleger (bewust) in een dossier kijkt van een persoon waar ze geen behandelrelatie mee hebben?

Juist ja, in geen enkele EPD discussie speelde dit enige rol.

Natuurlijk moet je hier flexibel mee om kunnen gaan, want als ik de EH binnen gedragen wordt, moet iedereen die mij dan helpt inzage kunnen hebben. Maar dat wil niet zeggen dat het dus maar helemaal niet besproken moet worden


Misbruik door bevoegden is een veel groter potentieel probleem dan misbruik door onbevoegde IMHO.

Niet alleen artsen hebben inzage in patienten dossiers. Dit zal vele mensen schokken, maar ik had als ICT uitzendkracht gewoon toegang tot alle dossiers... inclusief berichten uitwisseling tussen dokters en patienten. Ook analisten hebben vaak inzage in dossiers, soms zelfs helpdesk medewerkers.

Nu zou ik nooit misbruik maken van mijn positie, ik zocht alleen mijn eigen dossier op. Maar het feit dat dit mogelijk is, bewijst toch echt dat privacy al lang dood is.

In het UMC waar ik werk zijn reeds werknemers op staande voet ontslagen na het onterecht inzien van een medisch dossier van een patiënt waar zij geen behandelrelatie mee hadden. Bij het inloggen op het EPD wordt er ook gewaarschuwd dat er random gechecked wordt of inzage in het dossier wel legitiem is. Zoniet: zware disciplinaire straf.

Ik vind het een begin maar je suggestie om als patiënt te zien wie jouw dossier ingekeken heeft is eigenlijk het meest transparant.

Zou het niet mogelijk zijn om dit te intergreren in bijvoorbeeld een, voor de staat geldig, legitimatiebewijs, waarmee alleen jij toegang hebt tot jou EPD en verder niemand??

Misschien een raar idee, maar als je een authenticatiechip of iets dergelijks (heb geen idee hoe goed die te beveiligen zijn overingens) inbouwd in een 'document' wat iedereen verplicht is om altijd te kunnen laten zien, waar ze ook zijn. Dan moeten ze dat ook altijd bij hebben. In noodgevallen (mocht het dan kwijt zijn) kan er in eerste instantie niemand in je EPD, tot familie is ingelicht, familie heeft meestal ook enige kennis over een persoon zijn medische situatie.

De pas zal dan uiteraard ASAP geblokkeerd moeten worden, en als overheidsinstanties dan is op zouden schieten en binnen een week je nieuwe pas klaar hebben liggen dan is dat ook opgelost.

Ja inderdaad (Ik kan je niet omhoog modden, anders had ik het gedaan:-) Ik zou het nog verder willen uitbreiden: Waarom je EPD niet in zijn geheel op die pas? Dan heb je namelijk het voordeel van een gedecentraliseerd systeem, én het voordeel dat jij uitmaakt wie er wanneer toegang toe heeft.

Community? Open Source? Moet vast wel iets mogelijk zijn!

Wat wil je hiermee zeggen? We downloaden even snel iets, en installeren iets en we zijn klaar?

Closed source of opensource maakt hierin niet uit.

Integendeel - het zou hier een wereld van verschil maken. Er zijn bepaalde positieve eigenschappen van open-source software die hierbij erg goed van pas zouden komen (en die vermoedelijk dit hele scenario voorkomen hadden); denk hierbij aan transparantie ('hoe wordt mijn data opgeslagen en versleuteld?'), maar ook de mogelijkheid voor derde partijen om bij te dragen aan de code.

Als er open-source software gebruikt werd, was er zeer waarschijnlijk vrijwel direct na bekendwording van dit probleem een patch vrijgekomen van een ontwikkelaar ergens ter wereld, en zouden we niet hoeven wachten op een enkele commerciële ontwikkelaar om na anderhalve maand (!) een beveiligingsprobleem op te lossen.

Specifieker, een beveiligingsprobleem dat ervoor zou kunnen zorgen dat een groot aantal patiëntendossiers morgen op straat liggen, als de verkeerde (of juiste?) persoon dit nieuwsbericht leest.

DAT!

Transparantie zou echt enorm veel problemen schelen, er zouden zelfs devvers kunnen zijn die het complete pakket analyseren en het herschrijven in C++ zodat er geen runtime meer nodig is, om maar een voorbeeld te geven (ok, was misschien niet het beste voorbeeld, maar het gaat om het idee )

Als alle medische instanties hetzelfde stuk software gebruiken worden bestanden ook veel beter uitwisselbaar (althans, dat lijkt me wel logisch )

Mijn Bitcoins zijn namelijk ook (nagenoeg niet, maar de kans is echt verwaarloosbaar klein, 100% veilig bestaat niet) niet te hacken, de ING wel. Open vs. Closed.

Entire classes of bugs are missing.

Dan Kaminsky, Security Researcher
weusecoins.com

[Reactie gewijzigd door Eloy op 3 juni 2013 20:14]

Wat overblijft is de beste oplossing: Geen EPD.

Eén van de grote motoren achter het "nieuwe" EPD zijn de zorgverzekeraars. Uiteraard zullen die naar eigen zeggen geen inzicht hebben. Maar aangezien zij wel een groot belang bij die gegevens hebben, geld moeten verdienen voor hun aandeelhouders, zorgverzekeraars te veel macht hebben en macht corrumpeert, zijn zij eigenlijk wel de laatsten die er bij betrokken hadden moeten zijn.

Geen EPD is een illusie. Je dossier wordt al lang en breed digitaal opgeslagen. En ik vermoed dat jij op dit moment geen idee hebt waar je dossier staat en wie erbij kan. Laat staan hoe goed de server dichtgetimmerd is.

Dit is inderdaad zo. Het wordt nu al ergens centraal opgeslagen, en de beveilging daar is vaak geen kaas van gegeten.

Vanuit het EPD wordt zou dit juist centraal beheerd gaan worden, waardoor het een stuk beter te beheren zou zijn.

Het EPD zou het juist veiliger moeten maken.

Zou.....

Probleem met een dergelijk groot gecentraliseerd systeem is dat bij het mislopen er een verschrikkelijk groot probleem ontstaat. En aangeizen programmeren mensenwerk is zullen er fouten gemaakt worden en zullen er dus gaten blijven.

Momenteel zijn de problemen veel groter. Huisartsen die hun eigen servers hebben die slecht onderhouden worden. Accounts waar wachtwoorden van 6 cijfers op zitten die via internet te benaderen zijn, etc.

Nee, doe mij het EPD maar. Daar zal de beveiliging een stuk strikter zijn, en zullen zo'n simpele problemen wel opgelost zijn. Natuurlijk... Ieder ICT systeem is wel kwetsbaar om aangevallen te worden, maar het EPD zal een stuk veiliger zijn dan allemaal die kleine onafhnakelijk, vaak totaal niet beveildige servertjes die de huisartsen en apotheken momenteel gebruiken.

Helaas weet ik dat dus wel.

Er is al jaren samenwerking tussen artsen. Voorheen was dit vooral regionaal. Relevante data werd door artsen uitgewisseld bij noodzaak. Denk hierbij aan bijvoorbeeld Zorgdomein (digitaal verwijzen). Hoewel data weliswaar veelal centraal wordt opgelsagen (bijvoorbeeld op de servers van Promedico, FYI: vrijwel al deze data ligt opgeslagen in een bunker nabij schipho), maar niet centraal beschikbaar. Het EPD is niet direct een apart nieuw systeem, maar vooral het voor iedereen beschikbaar maken van ALLE patientgegevens, slechts beperkt doordat een arts (of ambulance persconeel) enkel voor hem/haar relevante gegevens in zou moeten zien.

In principe heeft een corrupte zorgverzekeraar maar één corrupte zorgverlener met toegang nodig om iemand zijn dossier te lichten.

Mijn huisarts wist niets over mij, juist omdat het dus wellicht digitaal wordt opgeslagen maar niet standaard wordt gedeelt als je naar een andere huisarts gaat, die dossiers bewaren zij dus soms intern, als jij naar een andere huisarts gaat heeft hij dus soms geen idee wat jou medische achtergrond is. Hij zou dan wellicht naar je verzekeraar moeten bellen of je medicijnen gebruikt of om te achterhalen wie je vorige huisarts was.

Eén van de grote motoren achter het "nieuwe" EPD zijn de zorgverzekeraars.

En op termijn waarschijnlijk ook degene die het gebruik gaan afdwingen. Niet rechtstreeks, maar door de patient zelf de keuze te laten maken; niet via een formulier, maar rechtstreeks via de portemonnee.

Nee hoor, deelname aan het EPD is niet verplicht. U mag zelf kiezen.
...
Ja meneer, ik zie dat er een buisje bloed is afgenomen. Als u had meegedaan aan het EPD, dan had dat niet gehoeven. Dus daarvoor dient u de kosten zelf te dragen.

Ik denk dat een vorm van een EPD de kosten in de zorg enorm kan drukken, zoals in het geval van het voorkomen van dubbele onderzoeken, verminderen van medicijn gebruik door beter inzicht enzovoort.
Maar alle extra troep die met de voordelen het EPD wordt binnen gerold, brrrr.....
Liever niet!

Bij een private partij heb ik nog de illusie dat die af en toe worden aangepakt en vervolgd. Wanneer het de overheid betreft, wordt het of de doofpot, downplayen of slap op de vingers tikken en wegpromoveren.

Het LSP (landelijk EPD) wordt door overheid noch bedrijfsleven ontwikkeld, maar door een expertisecentrum dat door beide is opgericht. De NICTIZ. Nog erger dus...

jah, mijn Huisarts heeft al zijn dossiers in Excel en er zit een Wifi verbinding op z'n computer...
Ik heb een licht vermoeden dat die Wifi verbinding niet beveiligd is.
Ik heb nog een donkerder vermoeden dat hij niet eens weet wat een Windows of Java update is.
Ik zou eigenlijk liever hebben dat hij gewoon met pen en papier schrijft... Alsof dat voor mij ook maar enige meerwaarde heeft, zo'n elektronisch dossier.

Ik zorg voor mijn eigen zaakjes: ik hou alles zelf bij en als er iets is dat hulpverleners moeten weten, dan zit dat naast mijn ID.

Trouwens, op het werk heb ik Java gewoon uitgeschakeld in 130 browsers sinds een maand. Nog niemand gehad die het gemerkt heeft. Dus tenzij het absoluut noodzakelijk is, Java uitschakelen in de browser! Eventueel het inschakelen beperken tot 1 site-bezoek.

[Reactie gewijzigd door ? ? op 3 juni 2013 13:46]

Ik hoop voor je dat je nooit een aandoening krijgt waar enige communicatie tussen verschillende zorgverleners bij nodig is.

"Even kijken, wat heeft u voor allergieën..." - oh wacht.
"Even kijken, wat voor medicatie heeft u..." - oh wacht.
"Gaat u maar even naar de apotheek met deze vier briefjes, succes ermee".
"Vertelt u het maar, wat is er aan de hand?" "Dat heb ik toch gisteren al aan mijn huisarts verteld?" "Ja, maar ik ben uw huisarts niet, en bovendien kon ik zijn verwijsbriefje niet lezen"
... etc.

Ik hoop voor je dat je nooit een aandoening krijgt waar enige communicatie tussen verschillende zorgverleners bij nodig is.

"Even kijken, wat heeft u voor allergieën..." - oh wacht.
"Even kijken, wat voor medicatie heeft u..." - oh wacht.
"Gaat u maar even naar de apotheek met deze vier briefjes, succes ermee".
"Vertelt u het maar, wat is er aan de hand?" "Dat heb ik toch gisteren al aan mijn huisarts verteld?" "Ja, maar ik ben uw huisarts niet, en bovendien kon ik zijn verwijsbriefje niet lezen"
... etc.

Volgens mij werken ze zo al enkele honderden jaren. En ja, daar worden ook fouten mee gemaakt, maar dat is tot op heden nooit een dusdanig groot probleem geweest dat we daarom alle gegevens maar op straat vegen.

Mijn chirurg ging met mij een gesprek in over een aanstaande operatie, kwam ik erachter dat hij dacht dat het om een totaal andere ingreep gaat. Hij had het handgeschreven briefje van de andere arts niet goed ontcijferd.

Vervolgens gaf een zuster mij per ongeluk 3x de dosis meds die ik had moeten krijgen omdat ZIJ een handgeschreven briefje niet begreep, en hadden ze tot op de operatie tafel toe niet doorgekregen dat ik allergisch was voor iets. Toch had ik dit echt al een dozijn keer verteld aan verscheidene dokters en verplegers die het 'ergens' opschreven.

Wat mij betreft mogen er kabels direct tussen medisch personeel worden gespannen want de onderlinge communicatie is echt bagger.

een arts met pen en papier... kom op zeg, heb je wel eens dokters briefje proberen te lezen? )

Nog opmerkelijker is het dat ze gebruik maken van (blijkbaar) FAT clients! Waarom kunnen ze niet als ASP (Application Service Provider) een SaaS dienst leveren met betrouwbare authenticatie? Zoals hierboven genoemd DigiD i.c.m. een Rijkspas.

bang voor downtime / spof denk ik...

Het is juist een SAAS applicatie. Maar ook Thin Clients moeten regelmatig moeten worden geupdated. En als je dan ook nog bagger software gebruikt zoals JAVA omdat het zo makkelijk te programeren valt Ja dan grote kans dat er zulke fouten op kunnen doen.. Dacht dat er achter Promedico ook een grote Oracle DB achter hing. waar alle dosiers opgeslagen zijn.

Wat is dan een betere cross-platform enterprise programmeertaal met bijbehorende omgeving en support dan?

Goede oplossing hoeft geen dedicated software zijn.. Je kan ook een webclient gebruiken met certificaat toegang, claims SMAL token enz.. Zijn zo veel verschillende beveiligings protocollen.. Nu gaat het verkeer ook over het net heen.

Java is een makkelijk stukje te programeren iets en vrij goedkoop daardoor.. Kies je voor een client pakket zal je voor Windows en OS X moeten programmeren misschien ook wel Linux.. Wat weer meer kosten met zich meebrengt..

Ja ik denk zelf dat een webclient net zo veilig kan zijn als een applicatie applet zoals Java. Sterker nog.. Het zou zelfs een stuk veiliger kunnen zijn.. mits je het juist implemeteerd.. Java moet daarnaast ook langzaamaan uitgefaseerd worden. bijna elke java versie is na een maand al weer als onveilig bestempeld. En Oracle is echt niet de snelste met het patchen van de applicatie

Ik denk dat het "fat-client" gedeelte alleen is om de uzi pas electronisch te kunnen lezen

Ik vind de titel een beetje overdreven, de laatste tijd lijkt Tweakers steeds meer SBS6 niveau aan nieuwsitems te publiceren...

Uiteindelijk is er dus een handje vol artsen die even moeten wachten met de update uit te moeten rollen omdat er in update 7.21 blijkbaar naast een paar lekken ook andere dingen zijn veranderd waardoor hun software niet meer correct functioneert. Dat kost nou eenmaal tijd om dat weer te verhelpen.

Ja, Promedico had dit sneller kunnen oplossen, maar om hier nou een nieuwsartikel over te schrijven...

Ik vind de titel een beetje overdreven

Bekijk eens de releasenotes met verbeterde beveiligingsmaatregelen en de bijbehorende security advisory met gefixte issues in Java 7 update 21. Oracle raadt niet voor niets aan zo snel mogelijk te upgraden.

Ja, Promedico had dit sneller kunnen oplossen, maar om hier nou een nieuwsartikel over te schrijven...

Door de woorden van Van Arkel ("In de loop van deze week zullen we onze software aanpassen") krijg ik het idee dat dit helemaal geen haast had totdat Tweakers vragen ging stellen.

[Reactie gewijzigd door Rafe op 4 juni 2013 09:14]

Ik vind de titel een beetje overdreven, de laatste tijd lijkt Tweakers steeds meer SBS6 niveau aan nieuwsitems te publiceren...

Helemaal mee eens.

Nee, helaas. De titel is precies juist. Als je je de UZI pas nodig hebt moet je een bepaalde versie van Java installeren die onveilig is. Het gevolg is dat op je computer dus een onveilig Java staat. En waarvoor heeft een huisarts die computer...? om zijn dossiers in bij te houden. Dus ja, huisartsen die de UZI pas nodig hebben worden gedwongen onveilig te werken.
En waarom heb je die UZI pas dan nodig? De UZI (unieke zorgverlener identificatie) is momenteel de meest veilige toepassing van beveiligd inloggen en het versleutelen van patienten gegevens, en die wordt hier gebruikt om in te loggen op het HIS (huisarts informatiesysteem). Je weet wie welke informatie raadpleegt en wie welke informatie heeft gemaakt. Bizar dat het UZI-register er zo lang over doet om dit te repareren!

Aan de andere kant, een haast klus er van maken, kan nog grotere schade toebrengen.
En misschien moet uzi ook wel wacht totdat een leverancier zijn software heeft geupdate naar een versie die kunnen kunnen gebruiken.

Het is helemaal niet overdreven! Juist een systeem wat toegang geeft tot zeer gevoelige patiënt gegevens moet optimaal beveiligd zijn. Het draaien op een brakke java versie met, neem mij niet kwalijk, een behoorlijk groot gat erin is nu niet het voorbeeld van goed beveiligd. Beetje idee van de voordeur op slot doen met drie nachtsloten en de achterdeur op een kier?

Zoals de naam het een beetje weggeeft, het betreft dus een ASP (web based) applicatie.

De client authenticatie gaat d.m.v. een token (de UZI-pas), welke communiceert met de webpagina middels JAVA.

Ofwel; het is een probleem van de UZI-pas (Java) login software. Dit wordt zo snel mogelijk opgelost. Dan is het toch duidelijk dat dit zo veilig / snel mogelijk getackeld wordt?
Dat het al langer dan een maand speelt lijkt misschien kwalijk, maar ik mag aannemen dat een goede OTAP + test fase wel zo een periode kan duren...

[Reactie gewijzigd door sjongenelen op 3 juni 2013 13:33]

Probleem is juist dat dit helemaal geen 1,5 maand mag duren.
testen van auth systeem kan makkelijk en vrij snel opgelost worden.

En zo'n spoed klus moet gewoon 24/7 aan gewerkt kunnen worden. en niet 9-5 met uitschietertje naar 6

testen van auth systeem kan makkelijk en vrij snel opgelost worden.

Maar als dit overal in verwerkt is, dan is het weer wat anders.

Daarbij zal misschien eerst de leverancier van de paslezers / uzi pas zijn software moeten updaten. En daarna kan men pas Promedico er mee aan de slag. 6 weken is dan heel netjes in een otap omgeving.

Dat het misschien sneller zou moeten ben ik met je eens. Maar als het slecht gedaan wordt, kan het nog erger zijn. Ook dat nieuws staat regelmatig op tweakers.

De take-away hier is het feit dat door de fabrikant expliciet wordt aangeraden een zeer onveilige versie van Java te blijven gebruiken.

Doe even normaal zeg met je op straat liggen van dossiers.
Het feit dat er een gat in Java zit betekent niet dat je meteen als $rand hacker kunt inloggen op het EPD. Overdrijven is ook een kunst.

De beveiliging van de PC's van die artsen komt in gevaar ja, wees blij dat de gegevens juist in het EPD staan en niet op de PC zelf.

[Reactie gewijzigd door Gert op 3 juni 2013 15:26]

Wat maakt het uit waar die gegevens staan? Als die website ook maar één website met gehackte advertenties bekijkt, dan is zijn pc besmet, en kan dus ook gewoon meegekeken worden in het EPD wanneer de huisarts daar is ingelogd. Zodra je in het epd netwerk zit heb je gewoon toegang tot alle gegevens, en je zit in het epd netwerk wanneer je toegang hebt tot een computer die inlogt op het epd, want dan kun je gewoon meeliften met de credentials die de arts gebruikt.

Nee dat kan dus niet, je moet namelijk ook de uzipas in je bezit hebben, het hele idee van 2 factor authenticatie.

En wat let de malifde nieuwe 'beheerder' van een geinfecteerd systeem om vrolijk te wachten tot iemand met UZI pas ingelogd is en dan alle gedecrypte data alsnog binnen te hengelen?

Juist ja; niets. Een kwestie van geduld om op die manier data te jatten, meer niet.

Een europees betaalpakket van ING Zakelijk weigert te functioneren op Java 7 en MOET Java 6 geinstalleerd hebben.
Lekker veilig je bankzaken doen

Java 5 6 en 7 branches worden/zijn gepatched. Java 6 of 7 zou niet uit moeten maken maar wel of het de laatste update is van de versie.

Ubuntu 12.04.2 LTS is ook niet automatisch minder veilig dan 13.04

Security Baselines
The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 7u21 are specified in the following table:

JRE Family Version JRE Security Baseline
(Full Version String)
7 1.7.0_21
6 1.6.0_45
5.0 1.5.0_45

Overigens benieuwd wat voor vage code zij hebben dat het stuk gaat met update.

//edit @RzrBck
Officieel is inderdaad java 6 EoL - als ik het goed begrijp (publiekelijk / voor consumenten)(zakelijk kan je het nog 5 jaar en als je genoeg betaald, nog langer) Echter zeiden ze bij update 41 al dat het de laatste was en hebben ze sinds dat bij elke update geroepen en inmiddels zitten we al op 45

if you look at the accompanying Oracle Critical Patch Update Advisory you will see it contains 42 security fixes. They match the fixes in the Java 7 Update 21 release.

http://java.about.com/b/2...-6-update-45-released.htm April 19, 2013

Ook gezien java 8 verder uitgesteld is, ging ik gemakshalve uit dat java 6 nog niet end of life was. (Ook gezien de tabel bij de release notes van 7 update 21) ...of misschien zijn ze vergeten te melden dat ze nog even door gaan

Zelf kijk ik al naar java 9/10 dingen die al bedacht waren voor java 5 zouden daar echt in moeten komen Je raakt dan wel eens de tel kwijt.

[Reactie gewijzigd door Mr_Light op 3 juni 2013 20:40]

Sinds maart 2013 wordt Java 6 (en 5 al langer) niet meer ondersteund door Oracle.

Dus het maakt wel uit of je 6 of 7 hebt. Want de meest actuele update van 6 - is nog steeds hopeloos out-dated.

Sinds maart worden versies voor Java 7 niet meer van een publieke update voorzien tenzij strikt nooit zakelijk. Als een bedrijf als bijvoorbeeld een ziekenhuis updates wil blijven ontvangen na de publieke EOL kunnen zij daarvoor een support contract met Oracle afsluiten.

Het kan nog erger, onze huisarts gebruikt nog gewoon één of andere DOS applicatie. Wel zo veilig...

Die "DOS applicatie", dat is waarschijnlijk Promedico

Promedico VDF is oud, Promedico ASP is de nieuwe goede betere cloud versie. Lang leve de cloud!

Even ter correctie:

Promedico ASP is een Web based applicatie van Promedico voor huisartsen, geschreven in java.
Promedico-VDF is een Windows based applicatie voor apotheekhoudende huisartsen.

Promedico VDF is de afgelopen 2 jaar complete herschreven en is een moderne Windows applicatie. Deze wordt momenteel uitgerold. De dos applicatie wordt momenteel dus uitgefaseerd.

Promedico VDF is dus niet oud!

Even ter correctie.

Hoeft niet.Het kan ook het oude Elias zijn, maar deze is wel opgeheven. Zie: http://www.computable.nl/...exhiscom-stopt-elias.html

Hoe weet je dat het een DOS applicatie is dan? Zijn veel van het soort kaartenbak-achtige applicaties voor bedrijven/dienstverleners die met opzet nog steeds met een tekst-mode interface worden gemaakt (ook onder Windows), omdat dat gewoon nog altijd best handig werkt als je elke keer precies dezelfde veldjes in moet vullen. Lekker grote letters, geen muis nodig, gewoon tabben en tiepen. Kassa-systemen zie je ook regelmatig met zulke interfaces, ook al zit daar meestal een custom OS achter...

Bij mijn huisarts is het DOS, heb het aan hem gevraagd toen hij ermee bezig was, verder melde hij ook nog dat hij Wordperfect gebruikte voor zijn brieven en verwijzingen.

Ken niet veel huisartsen die het verschil kennen tussen DOS, Windows, Linux, ...
Kan goed zijn dat het programma Dokter Office Systeem heet (om maar iets te zeggen) met dan DOS als logo of zo. Voor de gemiddelde dokter is dat dan in DOS dat ie werkt

Is er iets mis met Word Perfect misschien? Je doet het nu overkomen als een pakket van twintig jaar geleden maar de laatste versie is vorig jaar uitgekomen.

Dat is inderdaad erg veilig, mijn huisarts doet dit ook en het werkt al jaren prima, oke, de letters zijn niet van deze tijd meer net zoals de bekende ANSI lijnen, maar het doet wat het moet doen en nooit geen problemen met hackers, BSOD's en noem maar op. Vrijdag moest ik bellen naar de zorgverzekering en tijdens de invoer van gegeven gaf de man mij aan dat hij opnieuw moest booten omdat de boel vast zat, die bleek dus nog op Windows XP te zitten naar hij vertelde.

Veel artsen gebruiken een programma dat vanuit de webbrowser werkt. De opbouw van dat programma heeft veel weg van DOS, maar is dat dus niet. Promedico is er ook zo een.

De mijne ook, en daar ben ik erg blij om.
Dat soort ouwe meuk draait al zo lang dat we vrij veilig kunnen aanmenen dat het niet meer stuk gaat. en de backups gaan zover als ik weet eens per week op een CD-rommetje.

Goed systeem, veiliger wordt het niet!

Die kist hangt zelfs niet aan het internet, dus lekker oldschool in de encyclopedie bladeren komt daar ook weer gratis bij.

Ik ben een groot voorstander van vooruitgang in de techniek, maar dit soort ellende zijn daar de keerzijde van, en daar komen een hoop problemen van.

laat je oog je niet bedriegen, apotheken gebruiken ook een dos achtige applicatie, maar dat is gewoon een windows x86 applicatie

Wat is er mis met DOS? Dat iets oud is maakt het nog niet onveiliger.

Geef mij maar een huisarts met een koppeling naar de apotheek. Wel zo handig dat een recept direct bij de apotheek zichtbaar is.

Wat mij betreft zijn de voordelen van gekoppelde systemen in de zorg vele malen groter dan de nadelen. Het geeft meer zicht op eventuele interacties en dubbelmedicatie en kan vergissingen voorkomen.

Precies! En als je in Groningen verongelukt en allergisch bent voor bepaalde medicatie weet het ziekenhuis dat ook.

Precies! En als je in Groningen verongelukt en allergisch bent voor bepaalde medicatie weet het ziekenhuis dat ook.

Als je verongelukt, wat maakt het nog uit of je ergens allergisch voor bent ?

Ontopic: De telegraaf-titel is storend bij dit artikel. Verder komt Promedico binnen 7 weken na release van de laatste Java-release met een compatible systeem. Tja, als je pas aan de slag kunt na release... Hoe lang duurde het ook alweer voordat Java zelf een zware bug in haar systeem had gerepareerd? (kuch: tweakers)

[Reactie gewijzigd door Anoniem: 415735 op 3 juni 2013 14:08]

Als je verongelukt, wat maakt het nog uit of je ergens allergisch voor bent ?

Dat soort informatie kan van belang zijn bij vaststellen van de mogelijke doodsoorzaak.

Verder komt Promedico binnen 7 weken na release van de laatste Java-release met een compatible systeem.

Veel interessanter is de vraag waarom de software van Promedico niet compatible met de meest recente Java versie!

Kan het zijn dat er gebruik wordt gemaakt van onveilige constructies die nu niet meer werken?

Mijn huisarts heeft ook zo'n DOS-achtige applicatie, én gewoon een koppeling met de apotheek en de regionale huisartsenpost. Er is dus helemaal niks mis met die DOS applicatie.

Sterker nog, als ik wel eens op bezoek ben bij andere artsen dan zijn die vrijwel altijd tijd kwijt met het invullen van een entry in hun medische systeem, die moeten overal vinkjes zetten en keuzes maken uit drop-down menu'tjes wat gewoon vrij veel tijd kost. Mijn huisarts heeft daar dus geen last van, die vult hier en daar wat codes in en klaar...

Er is inderdaad niet zoveel mis met die dos applicatie. Maar daarover kan ik het volgende vertellen:

Het moet ook nog VERKOCHT worden. En de markt is helemaal verpest door gasten die kijken naar MOOI in plaats van FUNCTIONALITEIT. Een mooie applicatie die geen moer kan verkoopt stukken beter dan een lelijke applicatie die alles kan.

Wat is er mis met DOS? Dat iets oud is maakt het nog niet onveiliger.

Hm, DOS is in principe niet heel erg oud. Ik dacht toch echt wel dat ze een Apple II hadden, of iets soortgelijks.

Die oude dos applicatie is overigens ook van Promedico.....

tja.. oplossing voor probleem is heel eenvoudig. Door gewoon de client met java in een thinapp bubble te draaien. Prima als tijdelijke oplossing en zo kan je host helemaal naar de laatste update.

Je kan een java versie als plugin installeren voor de browser, en dan de browser starten vanuit die instance. Dan draai je de juiste javaversie alleen voor die website waar je moet inloggen voor dat patientendossier.

[Reactie gewijzigd door terracide op 3 juni 2013 14:22]

Ik denk dat de data dan ook in die bubble terecht komt, client is dan wel veilig maar de data dan niet...

nee dat gebeurd niet. Je kan zelf bepalen met isolationmodes wat waar komt. Het is nooit de bedoeling dat je data in een sandbox komt. Verder lijkt me het systeem gewoon volledig vanuit de browser werken, dus er is geen lokale data. Maar zelfs al was dat er wel is dat nog geen probleem.

Je browser start alleen vanuit een environment waar hij de juiste javaversie heeft, verder niets. Je hoeft niet eens de browser in een ThinApp bubble te doen alleen maar de javaruntime en vanuit die instance je browser starten.

[Reactie gewijzigd door terracide op 3 juni 2013 15:43]

Voor alle duidelijkheid: het gaat hier om het client-side inloggen middels een applet. De betreffende applet is blijkbaar nog niet bijgewerkt zodat deze met de sinds update 21 strengere veiligheidseisen goed omgaat.

Ik vind het nog steeds een kwalijke zaak dat men er op deze manier mee omgaat en pas zo laat de applet updatet, maar deze melding heeft geenszins betrekking op de veiligheid van gegevens. Die worden immers benaderd vanuit het serversysteem en daar is naar ik aanneem wel gewoon de nieuwste Java versie actief.

Het grote gevaar is dat de pc van de huisarts besmet raakt door de oude java versie en dat via die pc de gegevens op straat liggen.

Ik kan jullie uit eerste/eigen ervaring vertellen dat er grote Nederlandse zakenbanken met systemen zijn die van de client vragen dat de Java versie wel 15 updates achter loopt. Maakt niemand zich druk over en de AFM al helemaal niet.

Ik heb ook met open mond naar de helpdesk van een grote bank zitten luisteren die mij vertelde dat alleen versie 6 en eerder ondersteund wordt. Dit was eind vorig jaar en sindsdien nog een aantal keren terug gebeld met de vraag of ik al mag updaten maar nog steeds niets.

Iedereen die zegt dat EPD een slecht idee is is gek.
De miscommunicaties of helemaal niet communiceren is aan de order van de dag binnen de gezondheidszorg.
Mijn vrouw is zwanger en moet bloed laten prikken enzo. Dit moet ze bij priklocaties doen van de desbetreffende ziekenhuizen. Niet dat ze samen werken of de informatie deelbaar maken....Nee dat is dan weer te moeilijk. Of onveilig. Wat kan een vreemde met deze gegevens?
Verkopen.. aan de verzekering verkopen misschien? dan ben ik bang dat ze verzekeraar niet lang meer bestaat.
en ondertussen gebeuren er allerlei misstanden binnen de zorg om dat de EPD nooit is ingevoerd.
Altijd naar het negatieve kijken..dat helpt...echt...niet..
welkom in de 21 ste eeuw waar je voor een habbekrats je online gedrag verkoopt (voor een app), maar als je het een mogelijkheid is om makkelijker te werken enzo..dan wordt er een heel privacy disccusie aangehaald. Bah....bah...Alles is hackbaar. we kunnen beter positief naar oplossingen kijken om ons leven makkelijker te maken dan altijd de kont in de krip te gooien zoals die stemcomputers....Ja ze zijn gekraakt...moet je wel er langs staan om het apparaat er in te pluggen om hem te modificeren.. en dan het ergste vindt ik nog wel..die gast die er achter zat was de oprichter van een internetprovider...zo ontzettend raar...

Ik snap je punt heel goed! Maar zolang deze maatschappij nog steeds gericht is op geld verdienen blijf ik heel voorzichtig. Ze weten alles van je en kunnen daar op allerlei manieren inspelen.

Als de maatschappij verandert naar wat we voor elkaar kunnen betekenen zonder daar een wederdienst of geld terug voor willen hebben ga ik me pas minder zorgen. Ik zie dit alleen niet gebeuren zolang ik leef.

Toch een kanttekening: de communicatie tussen zorgverleners als ze WEL toegang hebben tot de gegevens. Bijvoorbeeld via het eigen dossier (binnen de dienst).

Daar gaat een EPD niets aan veranderen.

Mijn weerstand tegen EPD is dan ook slechts voor de helft wantrouwen richting de ICT, de andere helft is wantrouwen richting de medische staf.