Blog: de zorg in 2025

Jonge zorgprofessionals geven in Coach, Cure & Care 2025 hun visie over de zorg in 2025. De nieuwe orde noemt zelfredzaamheid van de patiënt als een van de pijlers van de moderne zorg. Met name innovaties op het gebied van  eHealth en  mHealth moeten hieraan bijdragen. Mijn ervaring is dat de innovatie al in volle gang is. Steeds meer zorginstellingen weten applicatieontwikkelaars te vinden, gaan samenwerkingsverbanden aan, of zijn bezig met de ontwikkeling van hun eigen platform met daarop informatie en een portal.

Alleen de praktijk anno 2013 leert dat vaak onvoldoende juridische en praktische maatregelen worden getroffen om veilig gebruik te kunnen maken van de online applicaties. Denk aan het onderzoek dat het College Bescherming Persoonsgegevens (CBP)

op 10 juli publiceerde. Daaruit bleek dat er bij online aanvragen voor herhaalrecepten door bijna een derde van de apotheekwebsites geen gebruik werd gemaakt van een beveiligde verbinding. Gevolg: gegevens kunnen relatief gemakkelijk gelezen, verwijderd of aangepast worden door een onbevoegde.

Eerlijkheidshalve moet ik toegeven dat goed regelen vaak geld kost. Terwijl eHealth ook de potentie heeft om kosten te besparen,  zijn de veiligheidseisen en kosten soms fors. Ik ben wel van mening, en de wet met mij, dat het geregeld moet worden. De kosten kunnen vaak beperkt worden door eerst de beveiligingsrisico’s van de applicatie te analyseren en daar de maatregelen en afspraken op af te stemmen.

Nadat de risico’s geanalyseerd zijn, kunnen er afspraken op schrift worden gesteld. Houd hierbij wel rekening met de praktische uitvoering van deze afspraken. Er moeten in ieder geval afspraken gemaakt worden over de volgende onderwerpen:

1. security en privacy aspecten bij ontwikkeling van, verbinding met en gebruik van applicaties;
2. continuïteit van de applicatie bij faillissement van dienstverlener;
3. exit strategie t.b.v. data als partijen uit elkaar gaan;
4. verdeling van verantwoordelijkheden en daaraan gekoppelde (beperking van) aansprakelijkheid van de zorgverlener en/of ontwikkelaar van de applicatie.

Voordat de applicatie ontwikkeld wordt, moeten er afspraken gemaakt worden over security- en privacy-aspecten (1). Uitgangspunt daarbij is om kwetsbaarheden in de software zo veel mogelijk te voorkomen. De belangrijkste kwetsbaarheden vind je in de top 10 van het OWASP (the Open Web Application Security Project). Op nummer 1 staat “injection”: je injecteert als het ware een stukje code waardoor het computer programma anders gaat werken of een bepaalde (ongeoorloofde) instructie uitvoert. Het gevolg kan zijn dat er meer informatie uit een database gehaald wordt dan toegestaan. Stel je voor dat er patiëntgegevens in de database zitten, dan begrijp je de wat de gevolgen kunnen zijn.

Ten aanzien van de verbinding kan ik kort zijn. Als er gegevens over een openbare internetverbinding worden verstuurd, dan moet afgesproken worden dat gegevens versleuteld worden verzonden. Voor een website geldt dat er versleuteld kan worden met gebruik van een SSL-certificaat. Online is een SSL-verbinding ook zichtbaar, in de browser adresbalk staat dan https in plaats van http.

'Rack' met servers. Foto: Google

Wat betreft de beveiliging van de applicatie voor veilig gebruik kun je denken aan het implementeren van normen. De wet stelt dat het verwerken van medische persoonsgegevens met passende technische en organisatorische maatregelen moet worden beveiligd. Hoe je deze open regel moet interpreteren wordt uitgelegd door het CBP in haar richtsnoeren. Hierin staat onder andere dat je bestaande normen moet hanteren (denk aan NEN 7510, ISO 27001, ISO 27002) of uitleggen waarom je dat niet hoeft te doen.

Ook continuïteit van de dienst (punt 2) en de data (punt 3) kan in meer of mindere mate geregeld worden. Hoe ver je daarin gaat hangt samen met de antwoorden op de vragen:

1. hoe lang mag de applicatie “down” zijn; en
2. mogen er gegevens verloren gaan, wat is een aanvaardbaar verlies?

Noodzakelijk is dat ingevoerde patiëntdata bij het einde van de dienstverlening (als je stopt met het gebruik van de applicatie) aan de zorginstelling en/of patiënt wordt geleverd. Voor data geldt: het is belangrijk om af te spreken hoe en in welk formaat (bijvoorbeeld een open source formaat) het wordt aangeleverd. Dat is noodzakelijk om de data te kunnen migreren naar een nieuw systeem.

Sommige eHealth applicaties zullen van zo’n groot belang zijn dat de continuïteit van de hele applicatie gewaarborgd moet worden.

Denk bijvoorbeeld aan een EPD in de cloud. Als een dienstverlener failliet gaat, heeft de curator het recht de stekker uit de dienstverlening te trekken. Een zorginstelling zou dan geen toegang meer hebben tot het EPD: een curator hoeft namelijk bestaande overeenkomsten niet na te komen. Om de continuïteit van de dienst en/of de data te regelen bij faillissement is er dus meer nodig dan enkel een overeenkomst. Vaak moeten er juridische en organisatorische maatregelen worden getroffen die in stand blijven, óók als de dienstverlener failliet gaat (lees hier meer).

Het voorbeeld van het faillissement van Info Technology laat zien dat de curator bij de beslissing naast het belang van de schuldeisers ook het algemeen belang kan laten meewegen. Info Technology was een hosting service provider die met name EPDs op zijn servers had staan. In dit geval heeft de curator ervoor gezorgd dat de servers niet direct offline gingen. Dat dit echter eerder uitzondering is dan regel wordt ook door de politiek bevestigd. Als de curator geen middelen heeft – als er kortom niets meer in de boedel zit - dan zal hij eerder de stekker eruit trekken. Dat is ook de reden dat Minister Schippers zorgverleners aanbeveelt zelf afspraken te maken over continuïteit.

De verdeling van verantwoordelijkheden (punt 4) en de daaraan verbonden aansprakelijkheid wordt vastgelegd op papier. Denk aan een algemene beperking van aansprakelijkheid in de algemene voorwaarden van de dienstverlener, of in de inkoopvoorwaarden van de zorginstelling. Een meer specifieke omschrijving kan in een overeenkomst en/of service level agreement en bewerkersovereenkomst. Deze laatste is verplicht als een ander (de bewerker) in jouw opdracht persoonsgegevens gaat verwerken. Hierin leg je de verantwoordelijkheden ten aanzien van de beveiligingsmaatregelen vast.

Bij punt 4 is enig praktisch inzicht in de online applicatie vereist. Een online applicatie draait vaak in de cloud. Dit houdt in dat de server bij een datacenter in een groot rek (“rack”) staat. Op de server draait de applicatie en de

databases waarin de ingevoerde informatie wordt verwerkt: via een internetverbinding kun je inloggen en gebruik maken van de applicatie. Het datacenter, het beheer van de server, de internetverbinding en de applicatie worden vaak door verschillende dienstverleners geleverd. Om te weten welke risico’s er zijn en hoe de verantwoordelijkheden verdeeld moeten worden, is het dus goed om hier inzicht in te hebben.

Toegegeven, dit is een serieuze lijst met voorwaarden en aanbevelingen. Ik denk dat bij juridische en praktische invulling van de afspraken het doel niet uit het oog moet worden verloren. Dat is dat eHealth de zelfredzaamheid van patiënten kan vergroten, en dat digitale gezondheidsinitiatieven zorg toegankelijker en misschien gemakkelijker kunnen maken. Transparantie tussen dienstverlener en zorginstelling, én enige technische kennis, zijn dan wel vereist. Mijn ervaring is dat deze afspraken innovatie niet in de weg hoeven te staan.