Toen ik zelf ruim tien jaar geleden startte met werken in de zorg-ict kreeg je als patiënt aan de balie van menig ziekenhuis nog een ponskaart en je medisch specialist hield bij gebrek aan een epd je medisch dossier bij op papier. Er is sindsdien veel veranderd in de zorg…
Er vinden in de zorg steeds meer positieve veranderingen plaats, die een grote invloed hebben op de wijze waarop zorg kan worden verleend. Zo is er meer hoogwaardige medische apparatuur beschikbaar, waarbij onderzoeken volledig digitaal kunnen plaats vinden. Ook kunnen patiënten zich steeds vaker zelfstandig vanuit huis redden, dankzij bijvoorbeeld domotica. Door de opkomst van allerlei slimme devices zijn ze in staat zelf metingen uit te voeren om hun eigen toestand te monitoren of op afstand te laten monitoren. De mogelijkheden en de verschillende vormen waarin ict binnen de zorg kan worden ingezet, nemen razendsnel toe. Dat maakt de zorgsector voor mij een van de meest interessante sectoren van dit moment.
eHealth
Als er een gebied is dat de laatste tijd veel aandacht krijgt, dan is dat wel ehealth. Vaak wordt dan verwezen naar de potentiële mogelijkheden van health apps. En dat is niet vreemd, want er is een enorme explosie op dat gebied gaande, die heeft gezorgd voor een onoverzichtelijke soep van health-apps met daarin soms ondefinieerbare stukjes, waarvan je je af kan vragen wat je er mee moet. Veel apps worden met de beste bedoelingen opgezet vanuit een functioneel idee waar behoefte aan is in de zorg.
Naar mijn idee wordt er daarbij te weinig stil gestaan bij een heleboel niet-functionele eisen. Dat is op zich niet erg wanneer een app geen patiëntgegevens gebruikt (een goed voorbeeld hiervan is de prijswinnende app ‘Moet ik naar de dokter?’ waarmee onnodig huisartsbezoek kan worden teruggedrongen). Zodra er echter met een app persoonlijke medische informatie kan worden vastgelegd, dan verandert de aard van de app en zal er ook aandacht moeten worden besteed aan de niet-functionele eisen, zoals veiligheid en betrouwbaarheid, die een grote invloed kunnen hebben op het succes van een health app.
Authenticatie
Allereerst moet de manier waarop een patiënt of een zorgverlener toegang krijgt tot een health app goed worden geregeld. Veel apps maken gebruik van een standaard authenticatiemethode als gebruikersnaam en wachtwoord combinatie. Gezien het feit dat er iedere drie seconden een identiteitshack plaatsvindt in de wereld en dat iemand alleen jouw gebruikersnaam en wachtwoord hoeft te achterhalen om bij jouw medische gegevens te komen, is het beter om gebruik te maken van een two- of multi-factor authenticatiemiddel. DigiD met sms is daar een voorbeeld van, maar ook dat wordt niet als toereikend gezien volgens de handreiking patiëntauthenticatie van Nictiz. Pas bij een middel dat gebruik maakt van meerdere factoren op basis van bijvoorbeeld persoonlijk certificaten in combinatie met een gecontroleerd uitgifteproces, is er sprake van afdoende veilige authenticatie. Voor zorgverleners is een dergelijk middel al geruime tijd voorhanden in de vorm van de uzi-pas. Zo’n pas biedt vele voordelen, omdat iedere zorgverlener er uniek mee kan worden geïdentificeerd bij alle zorginstellingen in Nederland. Vanwege een aantal praktische bezwaren moeten veel zorginstellingen echter nog beginnen aan de implementatie binnen hun organisatie.
Mobile environment management
Na authenticatie zijn er nog vele andere veiligheidsaspecten die een belangrijke rol spelen. Denk aan de wijze waarop het mobiele device met lokale data omgaat. Is deze data toegankelijk of wordt de toegang afgeschermd (bijvoorbeeld door gebruik te maken van containers)? Wordt de lokale data überhaupt versleuteld opgeslagen? Kan de data remote verwijderd worden in geval van verlies of diefstal van het mobiele device? Soortgelijke vragen kun je ook stellen over data in-motion, dat wil zeggen data die zich verplaatst tussen de app en de backend. Wordt deze versleuteld verstuurd? Wat voor verbinding wordt er opgezet? Is dat op basis van ssl of misschien wel op basis van een app-specifieke vpn? Hoe zijn de autorisaties geregeld? Kan overal vandaan verbinding worden gemaakt vanuit de app met de backend? Of speelt ook de context een rol?
Denk bijvoorbeeld aan een zorgverlener die ’s middag de app veilig gebruikt binnen de zorginstelling, maar waarbij er ’s nacht vanuit dezelfde app, maar dan met een afwijkend ip-adres vanuit een ver land, wordt getracht de backend te benaderen. De lijst met zaken waar je rekening mee kan houden is erg lang en vraagt om een holistische aanpak. Die aanpak wordt ook wel mobile environment management (mem) genoemd. Op het gebied van mem bestaan er oplossingen die kunnen worden geïntegreerd in bestaande health apps, zodanig dat aan veel aspecten van deze problematiek een goede invulling kan worden gegeven.
Integratie
Een ander belangrijk aandachtspunt is de integratie van een health app (of de backend van een health app) met bestaande zorgsystemen. Vaak vloeit een behoefte aan integratie voort uit de functionele eisen van een app en daar moet op de een of andere manier invulling aan worden gegeven. Dat is niet altijd eenvoudig. Het zou het makkelijkst zijn wanneer services eenvoudig kunnen worden aangeroepen en geïmplementeerd vanuit een veilige infrastructuur. Deze infrastructuur is binnen veel zorginstellingen niet aanwezig.
Vaak vormt binnen een instelling het eigen epd het centrale systeem, waarin zoveel mogelijk informatie van het medische dossier wordt opgeslagen. Veel deelsystemen op afdelingsniveau zijn daarmee gekoppeld en leveren informatie (bijvoorbeeld labuitslagen) of stellen informatie beschikbaar (zoals bijvoorbeeld beelden die over het algemeen op het Pacs blijven staan). De uitwisseling van dit soort informatie verloopt vaak nog via koppelingen op basis van bestaande standaarden (zoals HL7v2 of Dicom), die voor dit doeleinde volstaan. Nieuwere standaarden (zoals IHE XDS, HL7 FHIR of Restful Dicom) zijn helaas nog niet doorgevoerd in de vele zorgsystemen die binnen de instellingen staan. Ook hebben leveranciers van systemen er niet altijd belang bij om hun applicatie open te stellen met services die door andere partijen kunnen worden aangeroepen.
Denk bijvoorbeeld aan de epd-leverancier die misschien liever zelf app-functionaliteit ontwikkelt en meelevert met zijn epd dan dat hij deze services beschikbaar moet gaan stellen aan anderen. Gebrek aan mogelijkheden tot integratie of het daadwerkelijk doorvoeren van integratie binnen health apps kan leiden tot het ontstaan van de zoveelste nieuwe puntoplossing.
En nu?
Er zijn ongetwijfeld nog veel meer niet-functionele eisen die ik nog niet heb genoemd en waar nog dieper op in gegaan zou kunnen worden. Toch hoop ik dat deze vraagstukken de aandacht krijgen die ze verdienen. Gaan we hier niet serieus mee om, dan voorzie ik in de toekomst de nodige incidenten waarbij patiëntgegevens worden gestolen. Of nog erger: moedwillig worden gemanipuleerd. De gevolgen en ophef kunnen groter zijn dan die van een politicus van een ouderenpartij die zich toegang verschaft tot een beperkt aantal medische dossiers. Het is in ieders belang dat we de overgang maken van louter functionele health apps, die doen wat ze moeten doen, naar professionele health apps waar zowel patiënten als zorgverleners op een veilige en betrouwbare manier mee kunnen werken.
De bottleneck wordt hier treffend beschreven:
“hebben leveranciers van systemen er niet altijd belang bij om hun applicatie open te stellen met services die door andere partijen kunnen worden aangeroepen”
Daarom begrijp ik niet dat er niet meer druk is vanuit de politiek om FOSS te gebruiken en om meer samen te werken. Ik vraag me af hoeveel lobbyisten de politiek (proberen te) beinvloeden om dat te voorkomen.
@Jan
Schrijf nou eens een opinie over FOSS in plaats van te pas en te onpas roepen dat dit de oplossing is voor alle problemen. Soms lijk je net Henri die ook op elke vraag met het antwoord cloud komt. Die F in FOSS staat trouwens niet altijd voor gratis zoals jezelf ook wel weet, net als dat het ook niet altijd open is.
Jammer dat mijn eerdere artikel: ‘Open source of open sores’ wat ik eens geschreven heb voor een andere IT-titel niet meer online te lezen is maar daarin stelde ik dat open source nog niet altijd een garantie is voor een open standaard en openheid. Vooral FOSS met ASP licentie modellen (AGPL) hebben naar mijn opinie nog wat nadelen, open source is soms gewoon een marketing tool op zich zelf.
Ik heb persoonlijk de grootste moeite met de link Apps en EPD. Ik vind dergelijke visie en idee volkomen ‘out of order’. We zijn nog niet eens in staat Apps op juiste en goede merite te beschouwen en we komen al lang ogenschijnlijke Apps met goede toegevoegde waarde tegen die uiteindelijk een totaal andere App blijkt te zijn, met alle gevaarlijke gevolgen van dien.
Ik heb zelf een beetje de meer conservatievere mening dat men eerst maar eens naar een standaard toe moet werken voor men besluit Apps al of niet te connecten met het EPD. Zo weten we dat android en windhoos verre van veilig zijn en open source is perecies wat het zegt, open. Iedereen kan en mag aanhaken, dus ook de steeds slimmer wordende hacker.
Ik vlog Ewout hier even in zijn benadering dat er in Open source soms veel meer ‘eer’ te behalen is dan eerder genoemde platformen. Dat wil ik dus allerminst uitsluiten maar dan natuurlijk wel ordentelijk op IT merite beschouwd.
FOSS
In aanvulling van bovenstaande zou FOSS gewoon geheel buiten beschouwing moeten worden gelaten. Immers, telkens weer iets nieuws bedenken voor componenten die al onder de noemer ‘proven concept’ bestaan, kost vaak een hele hoop geld en leverd steeds minder rendement op.
Waarom zou je bestaande en proven concepts nou eindelijk niet eerst eens uit nutten, misschien een stukje perfectioneren, en dan gewoon inzetten? Dan hoeven we niet allemaal maar te blijven hypen dat die of gene het antwoord zou moeten zijn.
Al helemaal niet bij zoiets als een onderwerp met een dusdanige grote impat als EPD. Na 6,5 miljard in tien jaar nog geen veilig platform, en nog steeds ‘gesteggel’ over…. maar dan vooral door commerciele partijen en natuurlijk volkomen ridicule en incompetente ambtenaren en politici.
Eigenlijk zou dat hele epd gewoon maar eens ten grave moeten worden gedragen. Scheel vele honderden miljoenen die nog nodig zullen blijken voor een volkomen inadequaat en onveilig systeem.
Mijn gegevens in het EPD? Over my dead body. Zo simpel.
@NumoQuest: Hoewel het landelijk EPD en een lokaal instellings-EPD twee verschillende dingen zijn, kan ik me goed voorstellen dat er meer mensen zijn zoals jou die in beide gevallen niet willen hebben dat hun gegevens toegankelijk zijn. Toch zullen er aan de andere kant ook een hoop mensen zijn die er wel veel belang aan hechten dat zij inzage hebben in hun eigen gegevens of dat deze makkelijker kunnen worden uitgewisseld tussen verschillende zorgverleners in het belang van hun behandeling. Daarom wordt er in veel gevallen gewerkt met een opt-in waarbij je als patient kan verklaren dat je akkoord gaat met deelname. Zolang je niets aangeeft zullen jouw gegevens ook niet mogen worden uitgewisseld of kunnen worden opgevraagd.
Juist omdat die beweging sterk gaande is om medische data toegankelijker te maken voor zowel patienten als diverse zorgverleners binnen een zorgketen, zijn er een aantal partijen die niet gaan wachten tot een standaard volledig is uitgewerkt en uitgekristaliseerd en zelf aan de slag gaan. Een goed voorbeeld hiervan is het patientenportaal Medischegegevens.nl. Zij hebben voor verschillende EPD’s connectors gemaakt waarbij zij in staat zijn om data van de patient rechtstreeks over te halen vanuit een instellings-EPD naar hun eigen SaaS-platform. In principe is de instellings-EPD afgesloten van de buitenwereld en het portaal mag alleen data ophalen van patienten die akkoord zijn met de opt-in en die er zelf voor kiezen om hun eigen data te kunnen inzien. Juist dit soort pragmatische voorbeelden geven aan dat het wel degelijk mogelijk is om op een doordachte manier gegevens toegankelijk te maken zonder dat altijd alles volledig is gestandaardiseerd. Tegelijkertijd zie ik het belang van standaarden ook in. Daar wordt volop aan gewerkt op diverse terreinen, maar de weg naar volledige adoptie sectorbreed is een wat langere.