Mijn klant wil medische gegevens laten mailen, welke zorgplicht heb ik?

| AE 12804 | Privacy | 28 reacties

Een lezer vroeg me:

Ik ontwikkel een website voor een zorgverlener. Daarin zit ook een intake-formulier, waarin cliënten zich aanmelden en daarbij medische gegevens (bijvoorbeeld klachten of voorgeschiedenis) kunnen opgeven. De zorgverlener is een eenmanszaak en wil graag dat de gegevens naar hem gemaild worden vanuit het formulier. Ook moet de cliënt de optie krijgen om een kopie naar zichzelf te laten sturen ter bevestiging. Ik vind dat nogal onveilig, maar de klant staat erop. Hoe moet ik hiermee omgaan juridisch gezien?
De kern van de vraag is of e-mail wel een veilig medium is voor het transporteren van medische persoonsgegevens. De AVG stelt hoge eisen aan de beveiliging, en e-mail is natuurlijk niet inherent voorzien van de hoogste beveiliging. Het kan, maar je moet er wel je best voor doen. Denk aan situaties waarin de mailserver binnen hetzelfde domein draait als de website met het formulier, als die omgeving als geheel veilig is dan is natuurlijk dat mailtje ook beveiligd.

Vaak zie je echter dat men een oplossing inzet die voor ‘gewone’ bevestigingsmails (aanvraag offerte, inschrijving nieuwsbrief et cetera) gebruikt. De inhoud van het formulier wordt in een mailtje geplakt en via een standaardfunctie van je websitesoftware verstuurd. Ik zou dat een risico vinden, en daar dus aandringen op end-to-end encryptie of een gespecialiseerde oplossing. Een simpel alternatief kan zijn dat de medewerker een mailtje krijgt met een link naar de informatie, en dan moet inloggen op de backend van de website om de informatie te zien.

Specifiek bij de kopie naar de klant kan het anders liggen. Je kunt dan zeggen, de zorgvrager verzoekt met dat vinkje zelf om de kopie, en daarmee valt het versturen buiten de verantwoordelijkheid van de zorgaanbieder. Dan is er dus niets aan de hand. Alleen: weet de zorgvrager wel wat zhij vraagt met dat vinkje, of gaat die er vanuit dat de zorgaanbieder het veilig ingeregeld heeft? Dat laatste lijkt mij vrij waarschijnlijk. Bovendien ontkom je niet aan het feit dat de zorgaanbieder toch een en ander doet met die persoonsgegevens – en wel in opdracht, dus als verwerker namens de zorgvrager. En dan blijf je zitten met de beveiligingseisen.

Het lastige is natuurlijk dat e-mail over het algemeen wordt gezien als een handig en snel middel, en dat mensen de risico’s lastig kunnen inschatten. Want laten we wel wezen, de meeste mail infrastructuur is vandaag de dag voorzien van TLS verbindingen en stevige security op de transportservers. Het klassieke scenario dat iemand meeleest met de mail in transport, of een admin van een tussenliggende mailserver even koekeloert in de wachtrij lijkt mij ondertussen wel een beetje achterhaald. Maar met alleen het abstracte verhaal “je moet voorzichtig zijn met mail” kom je er niet als dienstverlener.

Wat is voor jullie het meest aansprekende risico dat je loopt met dit soort systemen?

Arnoud

Deel dit artikel

  1. Je zou ook PGP kunnen gebruiken om de inhoud van de e-mail te versleutelen en dan standaard de publieke sleutel van de zorgverlener gebruiken om het te versleutelen. Als een zorgvrager een kopie van de gegevens wil hebben via e-mail, moet deze zijn publieke PGP sleutel ook opgeven in het formulier. Nu snap ik dat de meeste mensen dit niet hebben, dus dan zou een alternatief kunnen zijn om de gegevens als pdf ter download aan te bieden aan de zorgvrager, zodat deze het toch kan krijgen.

  2. Dit soort beveiligingsvragen zijn inderdaad echt om te huilen. Je zou zeggen, geef de klant een portal access ( met gn / ww) op de website, zodat ze zelf bij de data kunnen wanneer ze dat willen binnen de beveiligde omgeving. Uiteraard met 2FA. Gevolg is dat 99% van de klanten er voor kiezen 2FA niet aan te zetten, als wachtwoord hetzelfde gebruiken als voor de bonuskaart, de praxis app, de ‘beveiligde’ omgeving van de volkstuinvereniging en nog 10 portals.

    De data is voor veel mensen veiliger bij Google mail. Dan is er in ieder geval goede logging wie er wanneer bij de data is geweest.

  3. Grote vraag is vertrouw je de mailbox aan de andere kant. 99% van het mailverkeer is onderhand wel TLS encrypted dus transport is wel geregeld. Maar als de eind mailbox niet veilig is en anderen kunnen daar kijken dan is dat niet handig. Een link naar een pdf in de email die direct opent is net zo veilig als het direct in de mail zetten. Inloggen met details die in de email uitgewisseld idem met wat extra stappen als de mailbox over genomen is. Evt code via SMS als tweede factor. Maar je zou ook een “bedankt klik hier om een pdf te downloaden met alle ingevulde gegevens” toe kunnen voegen. Dan kunnen ze zelf bepalen of ze dat willen en als ze het downloaden zelf zorgen dat ze het ergens veilig op slaan. Daarna is het niet meer op te halen.

    • Wat betreft veilige inbox. De klant die de gegevens via een formulier en mail wil ontvangen, moet daar in zijn omgeving voor zorgen. Het mechanisme waarmee het daarheen wordt verzonden moet door de bouwer van de site voor zorgen. Degene die de aanvraag indient, moet met een vinkje ervoor kiezen om een kopie te ontvangen en is zelf verantwoordelijk voor zijn eigen mailbox. Blijft het probleem, dat je e.e.a. nooit gegarandeerd veilig kunt krijgen via mail. Dus blijft het voor mijn gevoel beter, dat de klant een mailtje krijgt met de melding dat er een aanvraag ligt en hij met zijn eigen gegevens op de site inlogt. Als de site aan de voorschriften voldoet, is de bouwer van zijn verantwoording af en moet de klant op zijn eigen sh*t letten.

      • Ja, maar ik wordt helemaal gestoord van al die plekken waar ik moet inloggen, om goede of slechte redenenen (zo vermijd ik bijvoorbeeld zeer sterk webwinkels waar ik een account MOET aanmaken en niet gewoon kan bestellen met opgave van de verzendgegevens).

        Het probleem met een account is ook dat het dan lijkt of die documenten bewaard mogen/moeten worden door de sitebeheerder, terwijl bij email het duidelijk is dat dat een vluchtig medium is, dat door redelijk handelende providers niet bewaard wordt.

          • Ja, maar de verzendende server doet dat niet (lijkt me toch), en bij de ontvangende server ben je er zelf baas over: deleten in je client (ik krijg soms de indruk dat ik de enige ben die nog een client gebruikt (behalve outlook voor zakelijke dingen) is ook deleten op de server. (De provider zal een behoorlijke klus hebben om onder de AVG te verdedigen waarom ze de mail bewaarden als de client hem zelf verwijderd heeft).

            En natuurlijk, boeven heb je altijd, die dingen niet doen zoals ze horen.

            Ik blijf erbij: In het algemeen is email vluchtiger dan een account, omdat de tussenpersonen slechts als doorgeefluik, niet als opslagplaats gebruikt (horen te) worden.

        • Zodra je bij die webwinkel je verzendgegevens hebt ingevoerd heb je eigenlijk al een account aangemaakt. Het enige verschil tussen wel en geen account is dat je bij de volgende bestelling geen verzendgegevens hoeft in te vullen… 🙂

          Ik vind het zelf wel prettig dat ik per webwinkel een account kan maken. Ik heb namelijk ook mijn eigen domeinnaam met een catch-all mailbox. Dus voor iedere webwinkel maak ik een aparte email alias aan en kan zo goed zien of een bepaalde winkel gaat spammen of dat hun klantenbestand is gehackt. Dat laatste heb ik al meerdere keren opgemerkt voordat het in de media stond, waaronder met LinkedIn, Adobe en 3 kleinere webwinkels! Maar ook zonder account zul je dat merken omdat je bij bestellingen toch vaak een email adres moet opgeven voor een digitale factuur en bevestiging van je bestelling.

          • Ja, maar als ze hun AVG op orde hebben MOETEN ze die gegevens, als je geen account hebt, na een redelijke termijn verwijderen, omdat ze natuurlijk wel de noodzaak om de bestelling uit te voeren als verwerkingsgrond kunnen aanvoeren, maar na een zekere tijd (zeg, enkele maanden) niet meer.

            Ik neem aan dat er inderdaad wel een aantal zijn die daarmee flink sjoemelen, maar zo ZOU het toch moeten werken.

            • Ja, maar die redelijke tijd is nog best lang, want als klant heb jij natuurlijk garantie op je aankoop. Je gegevens kunnen ze dus gedurende al die tijd gewoon blijven bewaren. Daarnaast moeten ze ook vrij lang verkoopgegevens blijven bewaren voor de belastingdienst en boekhouding dus ga er maar van uit dat ze je gegevens rustig 5 jaar of langer vasthouden. (En 7 jaar voor je debiteuren/crediteuren administratie!)

              De AVG bepaalt ook niet hoe lang die bewaartermijn mag zijn, alleen dat de gegevens vernietigd moeten worden als ze niet meer nodig zijn. Je moet als webwinkel wel een bewaarbeleid hebben en deze schriftelijk vastleggen. Maar ga er maar rustig van uit dat ze deze jaren bewaren…

  4. Ik zie dat veel gebruik wordt gemaakt van Zivver. Zivver een oplossing waarmee de verklaring via end-to-end encryptie wordt verstuurd. Je kan die encryptie ontcijferen met een code. De code wordt via mail verstuurd. De ketting is zo sterk als de zwakste schakel.

    • Ik begrijp de reactie dat het dan niet waterdicht is, maar het voordeel van zo’n systeem als Zivver versus gewoon mailen is dat een afluisteraar (toch het meest waarschijnlijke risico) niet meer ongemerkt het kan lezen. Hij kan de code inderdaad afluisteren en dan inloggen, maar dat wordt gelogd en mogelijk over bericht dat het is in gezien. Daarmee is het mijns inziens wel een stuk veiliger omdat je weet wat er gebeurt, dan de gegevens ‘gewoon’ mailen.

  5. Wat ik ook wel tegenkom is dat de eigenaar van de website gebruikt maakt van Gmail en dus de webserver van de smtp-service van Google. Dat is natuurlijk funest voor de privacy en je kunt het aan domeinnaam/e-mailadres niet zien. Een beveiligd webformulier dat gegevens opslaat in een database is dan veiliger, mits de webserver goed beveiligd is en de gegevens niet onnodig lang bewaard worden. Ook dat is voor de klant lastig te controleren.

  6. Het klassieke scenario dat iemand meeleest met de mail in transport, of een admin van een tussenliggende mailserver even koekeloert in de wachtrij lijkt mij ondertussen wel een beetje achterhaald.

    Eh, what? Nee. In transport zal het dankzij TLS wel meevallen. Maar in de wachtrij kijken is nog steeds een heel reële mogelijkheid. Zelf moet ik dat nog wel eens doen ivm virussen en andere ongewenste troep. Maar ik zou dat ook echt wel kunnen misbruiken.

  7. Interessant artikel, denk dat er dagelijks veel mensen met deze vragen rondlopen! Het antwoord op je vraag is imo samen te vatten als “NTA 7516”, oftewel als je als zorgorganisatie voldoet aan de NTA 7516, dan kan je (medische) gegevens veilig mailen. Wil je eenvoudig en veilig kunnen mailen, dan is de NTA 7516 eigenlijk zowel de oplossing als een vereiste. Gelukkig kan je vrij eenvoudig aan de NTA 7516 voldoen. Laat me weten als ik je hiervoor een checklist kan sturen!

  8. Wat de beste oplossing is en/of email een oplossing kan zijn, dat is hier eigenlijk niet zo relevant. De vraag is in hoeverre de website bouwer een zorgplicht heeft. Het lijkt mij goed dat de websitebouwer dit aankaart, uitlegt wat het risico is, een alternatief beidt en als de klant vasthoud aan zijn vraag, alles schriftelijk wordt vastgelegd. Tenzij de websitebouwer een bijzondere rol heeft, is zijn klant verantwoordelijk en niet de websitebouwer.

  9. Mijn isp heeft standaard aanstaan dat TLS vereist is bij het versturen van mail. Als ik een mail stuur naar een ontvanger waarvan de mailserver geen TLS ondersteunt, krijg ik een bounce bericht met de tekst: “TLS is required, but was not offered by host”. Als je van zo’n feature gebruik maakt, weet je in ieder geval zeker dat TLS gebruikt wordt, alleen wordt er geen mail niet verstuurd als dat niet kan….

  10. Het meest riskante probleem is dat de email naar de verkeerde ontvanger gaat. Goede kans dat de ontvanger een GMail of Outlook account gebruikt en bij inschrijving een spelfout maakt. Dus sowieso zou de patient eerst zijn email moeten bevestigen via een bevestigings-mailthe en pas daarna kun je aannemen dat het adres klopt.

    Een ander probleem is eentje waar ik zelf last van heb. Ik heb een domein overgenomen van iemand die is overleden en de nabestaanden hebben daarna niets geregeld betreffende het domein, behalve de opzegging ervan. Het ging een tijd in quarantaine en kwam daarna beschikbaar. Maar ik wist dus niets van die voorgeschiedenis en bleek daarna best wel gevoelige informatie te krijgen van bedrijven die niet door hadden dat er nu een nieuwe eigenaar was. En dan vooral van bedrijven die maar af en toe een email sturen met een do-not-reply adres erbij.

    Kijk, bij websites en domeinnamen merk je al snel als er iets fout gaat maar email heeft gewoon te weinig controles. Je weet niet of het naar de juiste afzender gaat, je weet niet of het in een spambox komt en je weet niet of iemand anders het domein achter de emails heeft overgenomen en deze nu opeens elders heen gaan. Ik denk daarbij aan het oude Compuserve, waarbij Compuserve.com nog wel naar AOL gaat, maar compuserve.nl met .nl extensie is nu een casino-website! En ik heb ooit een Compuserve email adres gehad, net als heel veel anderen. (Jij ook, Arnoud?)

  11. Op dit ogenblik krijg ik hier in Zweden met een andere oplossing te maken. Voor het aanmelden/aanvragen van een vrijgave van opnames met een drone, vul je op de website van Lantäteriet een formulier in. Binnen een paar minuten dat je die formulier hebt ingevuld krijg je een mailtje met daarin een eenmalig te gebruiken link naar een uploadserver. Hier kan je max 30 GB uploaden (video, foto, logs etc). Is een dergelijke oplossing niet ook mogelijk in dit geval? Meldt je aan, je krijgt een link naar een veilige server en je kan alle documenten opsturen.

  12. Leuk bedacht hoor, al die end-to-end encryptie. PGP? Kom op zeg, niemand heeft zin om dat allemaal uit te zoeken en sleutels heen en weer te gaan mailen. Alleen al het feit dat de zorgaanbieder stáát op email als middel geeft al aan dat hijzij niet ver op de technologie vooruit loopt.

    Komt nog eentje bij. Ik vul mijn emailadres verkeerd in. Foutje, kan gebeuren. Vervolgens worden mijn gegevens dus naar een ander email adres gestuurd.

    Je moet dit probleem bij de bron aanpakken. Vertaal het probleem in: Je moet de gegevens veilig bij de zorgaanbieder krijgen en eventueel moet de klant die gegevens kunnen inzien. Ga vanaf daar iets ontwerpen, en niet met ‘het moet met email’.

    Nieuwe huizen krijgen geen gasaansluiting meer, we bouwen geen HTTP-websites zonder certificaat en we sturen geen geautomatiseerde mail met zorggegevens. Welkom in 2021.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS