De NTA 7516 eist dat aanbieders van veilige e-mail ‘koppelen’. Wat houdt deze interoperabiliteit in?

8 min lezen - gepubliceerd op 14 oktober 2019

In onze eerdere blogs hebben we al stilgestaan bij de norm voor veilige ‘ad hoc communicatie’ van gezondheidsinformatie, de NTA 7516, die de NEN in mei 2019 heeft uitgebracht. Zoals beschreven is het belangrijkste doel van deze norm duidelijk maken wat er onder ‘veilig’ wordt verstaan als het gaat om ad hoc communicatie, zoals e-mail. Een ander belangrijk doel van de norm is regelen dat oplossingen van veilige e-mail ‘met elkaar praten’, zodat ontvangers met een eigen NTA 7516-compliant oplossing berichten ‘gewoon’ kunnen lezen in hun eigen omgeving. Dit noemt men interoperabiliteit. Zoals je dat gewend bent van telecomproviders: met elkaar kunnen communiceren ongeacht de provider van de verzender of ontvanger. Mits de provider zich natuurlijk conformeert aan de 'koppeltaal’ die is afgesproken. Want zonder gedeelde taal, geen interoperabiliteit. Klinkt logisch, toch? Maar in dit blog leggen we uit wat dit concreet betekent voor leveranciers en organisaties en waarom dit veel minder makkelijk is dan het lijkt.

Wat is interoperabiliteit?

De eerste vraag is natuurlijk “Wat is interoperabiliteit?”. Volgens Wikipedia is dit ‘de mogelijkheid van verschillende autonome, heterogene systemen, apparaten of andere eenheden (bijvoorbeeld organisaties of landen) om met elkaar te communiceren en samen te werken. Om dit te bewerkstelligen zijn standaarden, protocollen en procedures nodig voor de afstemming van de verschillende entiteiten op elkaar’. Samengevat het met elkaar communiceren van verschillende systemen op basis van standaarden. Dus zonder standaarden geen interoperabiliteit. Zonder standaarden voor fittingen van lampen, hadden we geen ledlampen van verschillende leveranciers in onze lampen kunnen gebruiken. Zonder een standaard voor stopcontacten en stekkers, hadden we niet elk apparaat in elk willekeurig stopcontact kunnen steken.

En wat er gebeurt als er niet een uniforme standaard is, merk je als je naar het Verenigd Koninkrijk reist. Als je geluk hebt kun je, net als voor stopcontacten, een adapter gebruiken om de ene standaard aan de andere standaard te koppelen. Als je pech hebt zul je een andere standaard moeten gaan gebruiken, zoals wanneer je aan de linkerkant van de weg moet rijden. Dus uniforme standaarden waar alle leveranciers zich aan aanpassen zijn de sleutel tot interoperabiliteit.

Waarom waren afspraken over interoperabiliteit nodig?

Om dit beter te duiden volgt hier een korte schets van de huidige stand van communicatie. E-mail is nog steeds de meest gebruikte communicatievorm. Medewerkers spenderen gemiddeld twee uur per dag aan het werken met e-mail! Het mooie van e-mail is dat vrijwel iedereen het snapt, toegang tot e-mail heeft en dat er standaarden voor zijn. Het gaat om verschillende standaarden die in de loop der tijd zijn uitgebreid of aangevuld, waaronder SMTP, StartTLS, etc.

Het nadeel van deze standaarden is echter dat ze, mede doordat ze stammen uit een tijd waarin veiligheid nog niet top of mind was, onvoldoende in staat zijn om de veiligheid te bieden die nodig is voor het uitwisselen van gevoelige gezondheidsinformatie. E-mail is namelijk een zogenaamd opportunistisch protocol, waarbij het daadwerkelijk afleveren belangrijker is dan de veiligheid. Daarnaast zijn er geen standaarden waardoor het mogelijk is om berichten te beschermen met twee-factor-authenticatie (2FA), zoals je bank, DigiD, patiëntportaal etc. wel doen. Alleen met 2FA kun je zeker weten dat alleen de beoogde ontvanger een bericht kan lezen en niet een beheerder of iemand die (onbevoegd) toegang heeft tot een mailbox. Terwijl dat bij dit soort gevoelige informatie wel een eis is vanuit de AVG en andere wet- en regelgeving.

Om deze tekortkomingen van e-mail te compenseren zijn leveranciers, zoals ZIVVER, oplossingen gaan maken die wel de benodigde veiligheid bieden. Elke leverancier heeft echter zijn eigen oplossing bedacht, waardoor er inmiddels een aanzienlijk aantal losse oplossingen bestaat dat niet met elkaar praat. Met als gevolg dat ontvangers last hebben van het feit dat de verzender een andere oplossing heeft gekozen dan zij en meestal moeten inloggen op een, vaak onhandig, portaal van een ander product. Wat niet alleen onhandig is, maar ook inefficiënt en communiceren niet vergemakkelijkt. Om dit te verhelpen waren bindende afspraken over interoperabiliteit nodig.

Hoe is de standaard tot stand gekomen?

In de periode van april 2019 tot augustus 2019 zijn alle betrokken leveranciers door VWS uitgenodigd om te participeren in het opstellen van de zogenaamde “Technische handreiking NTA 7516 voor e-maildienstenleveranciers”, vanaf nu de handreiking. Een variërende samenstelling van circa vijftien leveranciers is in totaal zes keer samengekomen om toe te werken naar een gedragen veilige e-mailstandaard. Een belangrijk uitgangspunt was dat deze standaard ‘open’ moest zijn, oftewel geïmplementeerd kan worden door elke willekeurige partij. Een ander belangrijk uitgangspunt was dat deze standaard zo veel mogelijk gebruik moest maken van bestaande standaarden.

Eind september 2019 is de definitieve versie van de handreiking daadwerkelijk gepubliceerd! Het mooie van de handreiking is dat alle betrokken leveranciers, op 1 kleine speler na, formeel bevestigd hebben aan VWS de veilige e-mailstandaard beschreven in de handreiking te ondersteunen. Kleine kanttekening is dat het voor geen enkele partij de ideale standaard was, maar dat was gezien de verscheidenheid aan leveranciers, hun belangen en de tijdsdruk ook niet te verwachten. Dit betekent dat alle leveranciers aanpassingen moeten doorvoeren.

Welke standaard voor interoperabiliteit is in de NTA 7516 afgesproken?

Zonder te veel op de techniek in de gaan, is het mooie van de in de handreiking vastgelegde standaard voor veilige e-mail, dat deze voor het grootste deel gebaseerd is op bestaande standaarden. Hieronder SMTP, STARTTLS, DANE, DNSSEC, AES die allemaal ook voorkomen op de zogenaamde ‘pas-toe-of-leg-uit’-lijst; een lijst van standaarden van het forum standaardisatie waar overheden (rijk, gemeenten, provincies en waterschappen),

semi-overheden (uitvoeringsorganisaties zoals UWV en SVB) en private instellingen met een publieke taak in de zorg (zoals ziekenhuizen) en het onderwijs (zoals scholen en universiteiten) zich zo veel mogelijk aan dienen te houden.

Nu de standaard. De NTA 7516 legt de verantwoordelijkheid bij de verzender om te zorgen dat informatie veilig en geauthentiseerd bij de ontvanger terecht komt. Deze verantwoordelijkheid van de verzender vloeit voort uit de AVG en specifieke aanwijzingen van de AP rondom toegangsbewaking. Vanuit het oogpunt van interoperabiliteit is het echter wenselijk/noodzakelijk om het mogelijk te maken deze verantwoordelijkheid over te dragen aan een ontvanger die zelf ook voldoet aan de NTA 7516. Door te voldoen aan de NTA 7516 geeft deze organisatie de garantie dat zij zelf zorg draagt voor passende beveiliging van berichten en authenticatie van gebruikers binnen haar eigen omgeving. Voor ontvangers waarbij niet vastgesteld kan worden of ze voldoen aan de NTA 7516, blijft het dus de verantwoordelijkheid van de verzender om zelf, op een methode/met een leverancier naar keuze, te zorgen dan informatie veilig en geauthentiseerd wordt overgedragen.

We gaan in deze blog niet beschrijven hoe interoperabiliteit technisch werkt. Daarvoor is het lezen van de (29 pagina’s tellende) handreiking, die over een paar weken publiek beschikbaar komt, waarschijnlijk het beste. Maar het figuur hieronder laat conceptueel zien welke controles en bijbehorende acties voor een verzender nodig zijn om een bericht veilig bij een ontvanger af te leveren. Samengevat komt het op het volgende neer:

  1. Als een bericht persoonlijke gezondheidsinformatie bevat, dan moet de mail veilig worden afgeleverd;
  2. De verzender moet controleren, op de in de handreiking beschreven wijze, of de ontvanger zelf claimt (certificering voor organisaties is nog niet mogelijk) aan de NTA 7516 te voldoen en dus veilig e-mails kan ontvangen en verwerken;
  3. Als de claim ontbreekt (bijvoorbeeld bij een patiënt of burger) of de informatie in de claim niet klopt, dan moet de verzender zelf zorgdragen voor veilige aflevering bij en authenticatie (bijvoorbeeld via SMS) van de ontvanger op een zelf gekozen wijze/met een eigen leverancier.
  4. Als de ontvanger wel NTA-compliance claimt en de informatie in de claim klopt, dan moet de verzender proberen een veilige en geverifieerde verbinding tot stand te brengen met de e-mailserver van de ontvanger, zoals beschreven in de handreiking.
  5. Als het niet lukt om een veilige en geverifieerde verbinding met de e-mailserver van de ontvanger tot stand te brengen, dan moet de verzender zelf zorg dragen voor veilige afleveren bij en authenticatie van de ontvanger op een zelf gekozen wijze/met een eigen leverancier.
  6. Als het wel lukt om een veilige en geverifieerde verbinding met de e-mailserver van de ontvanger tot stand te brengen, dan moet de verzender het bericht veilig afleveren bij de e-mailserver van de ontvanger. De verzender moet daarbij vastleggen (loggen) welke stappen zijn doorlopen.

Als deze stappen zijn doorlopen dan ontvangt de ontvanger een ‘gewoon’ bericht, waarbij de ontvangende organisatie verantwoordelijk is geworden voor de beveiliging van het bericht en de authenticatie van toegang tot het bericht. Klinkt logisch, toch?

Wanneer is interoperabiliteit een feit?

Deze vraag is helaas moeilijk te beantwoorden. Zoals gezegd is het mooie van deze standaard dat alle circa 15 betrokken leveranciers (behalve 1 kleine) zich uitgesproken hebben voor deze standaard. Dat betekent dat alle leveranciers inhoudelijk akkoord zijn over het feit dat deze standaard de best mogelijke oplossing is. Maar het er mee eens zijn, is iets anders dan het ook gaan ontwikkelen. Hierbij spelen namelijk de volgende vragen een rol:

  • “Zijn wij in staat om technisch het gat tussen de huidige werking van het product en gewenste werking te overbruggen?”. Leveranciers met ‘oudere’ systemen die met open source software een veilige verbinding tussen twee mailservers verzorgen, en daar zijn er wel een aantal van, hebben een heel veel grotere uitdaging dan leveranciers die al zelf e-mails versturen en authenticatie, logging etc. geregeld hebben.
  • “Denken wij onze investering te kunnen terugverdienen?”. Alle leveranciers zullen aanzienlijk moeten investeren om deze standaard te gaan implementeren. Van enkele tot vele honderdduizenden euro’s. Uiteraard gaat een leverancier deze investering alleen maar doen als hij/zij deze investering denkt terug te gaan verdienen. Als je een product hebt dat alleen maar marktaandeel verliest en je ziet dat je een aanzienlijk minder sterke propositie hebt dan een ander, is het maar de vraag of de investering rendeert.
  • “Is dit de beste besteding van onze resources?”. Je kunt je geld maar een keer uitgeven. Als je andere producten/functies hebt die ook investering vragen en je daar een hogere ‘return on investment’ op verwacht, is het moeilijk om de investering in NTA 7516-interoperabiliteit te verantwoorden.

Tot welke antwoorden verschillende leveranciers komen is natuurlijk de vraag. Maar feit is dat er een aanzienlijk aantal partijen op een of meerdere van bovenstaande vragen ‘nee’ zal antwoorden. Deze leveranciers zullen samenwerking met andere partijen zoeken die wel de investering gaan doen, zoals KPN recent hun samenwerking met ons aankondigde. Of deze leveranciers gaan hun klanten teleurstellen met de boodschap (toch) niet aan de gewenste of beloofde onderdelen van de NTA 7516 te gaan voldoen. Hopelijk bereiden organisaties zich goed voor door al gedetailleerd uitgevraagd te hebben op welke onderdelen hun leverancier gaat voldoen.

Wij als ZIVVER hebben bovenstaande vragen ook voor onszelf beantwoord. Daarbij was het antwoord op vraag 1 en 2 voor ons ja. Maar het antwoord op vraag 3 was lastiger. Als we naar onze ideeën keken, waren er functies en modules waar we een veel hogere ROI op verwachten dan op interoperabiliteit. De investering die wij in het realiseren van interoperabiliteit moeten doen, hebben we geschat op ruim twee manjaar! Maar we hebben deze vraag toch met ‘ja’ beantwoord. De reden is dat we vinden dat wij hierin een maatschappelijke plicht hebben. Een plicht om de zorg te helpen niet alleen veilig, maar ook makkelijk te communiceren. En daar hoort interoperabiliteit bij. Daarom zijn wij inmiddels begonnen met het implementeren van de standaard die in de handreiking staat beschreven. 

Zorg dat je op de hoogte bent van alle ins en outs van de nieuwe norm:

Lees alles over de NTA 7516

Picture of Rick Goud

Rick Goud

Rick heeft ruim 6 jaar gewerkt als strategieconsultant in de gezondheidszorg bij Gupta Strategists. Hij studeerde medische informatiekunde aan de UvA en Zorgmanagement aan de Erasmus Universiteit. Daarnaast is hij gepromoveerd in de Geneeskunde aan de UVA op de ontwikkeling, implementatie en evaluatie van beslissingsondersteunende systemen in de zorg. Tijdens zijn studie heeft Rick een aantal jaar als programmeur gewerkt. Het idee achter ZIVVER ontstond tijdens zijn werk als strategieconsultant. Overal waar hij kwam werd veel met gevoelige data gewerkt zoals patiëntgegevens, prijsafspraken, marktprestaties, contracten etc. Bij elke klant speelden vragen over veiligheid van de data, hergebruik van de data, etc. Regelmatig zag hij dat gebruik gemaakt werd van oplossingen waarbij de veiligheid en beheersbaarheid onduidelijk was. Op basis hiervan zag hij dat er een duidelijke behoefte was aan een oplossing zoals ZIVVER die biedt.