Le nouveau service de pseudonymisation d’eHealth offre des garanties de sécurité élevées. Il est actuellement utilisé pour protéger la vie privée des citoyens, notamment lors du stockage et du traitement des ordonnances électroniques. Ce service se prête en outre particulièrement bien au croisement et à la pseudonymisation de données à caractère personnel dans le cadre de projets de recherche. Le présent article expose la manière dont cela serait possible d’un point de vue conceptuel.

Le service de pseudonymisation à l’aveugle d’eHealth

Le service de pseudonymisation à l’aveugle d’eHealth a déjà été décrit en détail dans un article précédent. Nous reprenons ici le scénario où un médecin (client) demande au service interne de prescription (owner) d’enregistrer une prescription électronique.

L’illustration 1 expose le flux de base: le médecin demande au service de pseudonymisation de convertir un identifiant en pseudonyme. Le médecin envoie ensuite le pseudonyme avec les données de l’ordonnance au service internet de prescription, qui stocke les données de la prescription sous ce pseudonyme.

Illustration 1. Flux de base pour le scénario où un médecin (client) demande au service de prescription (owner) d’enregistrer une prescription électronique.

Afin d’atteindre un niveau de sécurité élevé, les dispositifs de sécurité suivants sont essentiels :

1. Le client est hypermétrope: il ne voit que les identifiants globaux (numéros de registre national).
2. Le owner (propriétaire) est myope: il ne voit que les identifiants locaux (pseudonymes).
3. Le service de pseudonymisation est aveugle: il ne voit ni les identifiants ni les pseudonymes.

L’illustration 2 présente comment cela est possible en ajoutant un certain nombre d’étapes au flux de l’illustration 1.

1. La caractéristique de sécurité service de pseudonymisation aveugle (3) est réalisée à l’aide des opérations blind et unblind (indiqué en violet). Le numéro de registre national du patient est masqué, ce qui correspond à un chiffrement de courte durée avec une clé qui n’est utilisée qu’une seule fois. Le service de pseudonymisation convertit le numéro de registre national masqué en un pseudonyme masqué, sans voir ni le numéro de registre national d’origine ni le pseudonyme résultant (oubliez les opérations indiquées en bleu et orange pour le moment ; nous y reviendrons plus tard). Seul le client peut lever l’occultation effectuée par blind à l’aide de l’opération unblind.
2. Dans le flux de base de l’illustration 1, le owner ne connaît aucun numéro de registre national, de sorte que la caractéristique de sécurité owner myope (2) est déjà réalisée.
3. Enfin, grâce aux opérations encrypt et decrypt (indiquées en orange), la caractéristique de sécurité client hypermétrope (1) est réalisée: le service de pseudonymisation chiffre le pseudonyme occulté de sorte que seul le owner puisse le déchiffrer.

Enfin, la réutilisation non autorisée des pseudonymes chiffrés – que le client obtient après l’opération unblind – est évitée parce que le service de pseudonymisation utilise l’opération add context (en bleu) pour ajouter des informations contextuelles au pseudonyme chiffré, telles que l’heure de création. Le owner vérifiera ces informations à l’aide de l’opération verify context (en bleu) et n’acceptera que les pseudonymes chiffrés reçus qui ont été créés récemment.

Illustration 2. Flux High security pour le scénario où un médecin (client) demande au service de prescription (owner) d’enregistrer une prescription électronique.

L’opération convert

Dans la section précédente, le service de pseudonymisation a appliqué spécifiquement l’opération pseudonymise pour convertir les numéros de registre national en pseudonymes. Dans certains scénarios, l’opération inverse est également nécessaire, à savoir l’opération d’identification, où un pseudonyme connu du owner est reconverti en numéro de registre national d’origine du côté d’un client.

Les systèmes (owner) communiquent également les uns avec les autres. Un service sur la plateforme eHealth pourrait demander au service TherLink si un patient a une relation thérapeutique avec un médecin en particulier. Si TherLink utilise également des pseudonymes, le pseudonyme d’un service/owner devra être converti en pseudonyme de l’autre service/owner. Cela s’effectue à l’aide de l’opération convert. En effet, afin de minimiser le risque d’identification, il convient de ne pas réutiliser les pseudonymes dans plusieurs services.

Ainsi, les trois opérations que le service de pseudonymisation doit prendre en charge sont pseudonymise, identify et convert. Nous verrons que les opérations pseudonymise et convert sont toutes deux utiles pour croiser et pseudonymiser des données à caractère personnel. À l’inverse, l’opération identify nous permet de procéder à l’identification contrôlée des citoyens. Cela peut être souhaitable dans certaines situations, par exemple lorsque des chercheurs découvrent que certains citoyens courent un risque très élevé de souffrir de certaines maladies, ou qu’ils en sont déjà atteints sans le savoir.

Croisement des données à caractère personnel – l’approche actuelle

Pour les besoins de la recherche, les données à caractère personnel provenant de différentes sources sont régulièrement croisées et pseudonymisées. Cette dernière mesure est nécessaire pour empêcher le chercheur d’établir un lien entre les données à caractère personnel et les personnes physiques.

Prenons comme exemple concret la délibération 13/093 du 22 octobre 2013, qui donne à Sciensano l’accès à des données médicales provenant de différents hôpitaux, dans le but d’obtenir des informations sur l’épidémiologie des patients atteints de diabète. Ce faisant, Sciensano ne découvre pas de numéro de registre national, mais uniquement des pseudonymes.

L’illustration 3 montre – de manière quelque peu abstraite – comment cela est fait à ce jour en utilisant eHealth Batch Codage, un service de pseudonymisation qui existe depuis un peu plus longtemps que notre service de pseudonymisation à l’aveugle. data^A_id est la donnée relative au citoyen avec le numéro de registre national id fourni par l’hôpital A.

Pour chaque citoyen concerné, les hôpitaux envoient les données demandées directement à Sciensano et le numéro de registre national à eHealth Batch Codage. Ce dernier convertit le numéro de registre national en un pseudonyme spécifique au projet, le pseudonym^link_id, et envoie ce pseudonyme à Sciensano. Sciensano reçoit donc les données provenant d’un hôpital par un canal et les pseudonymes provenant de Batch Codage par un autre canal. Grâce à un pseudonyme de transit temporaire (par exemple nym^A_id), qui est caché à Batch Codage, Sciensano est en mesure de relier les données aux pseudonymes spécifiques au projet. Enfin, grâce à ces pseudonymes spécifiques au projet, Sciensano peut relier des données concernant le même citoyen mais provenant de sources différentes.

Illustration 3. Croiser et pseudonymiser les données à caractère personnel provenant de plusieurs hôpitaux et destinées à Sciensano, comme décrit dans la délibération 13/093.

Cette approche présente un certain nombre d’inconvénients :

• Le Batch Codage doit être fiable. Il s’agit d’un tiers de confiance (Trusted Third Party TTP) ; il voit à la fois les numéros de registre national entrants et les pseudonymes sortants. Il sait à quel projet de croisement il collabore et peut donc théoriquement établir des profils pour chaque citoyen ; par exemple, après deux projets, il sait quels citoyens ont participé à la fois à la recherche sur le diabète et sur la sclérose en plaques. Ces profils pourraient éventuellement contenir un grand nombre d’informations sensibles.
• Deux canaux de communication. Sciensano devrait être en mesure de relier les données reçues directement des hôpitaux aux pseudonymes reçus du Batch Codage. Bien qu’il existe une solution, il serait plus élégant que toutes les informations soient envoyées directement de l’hôpital à Sciensano par un seul canal.
• Mauvaise intégration lorsque les données sont pseudonymisées. Ce système ne peut pas traiter de manière élégante les situations où une ou plusieurs sources de données utilisent déjà le service de pseudonymisation à l’aveugle décrit plus haut et n’ont donc pas elles-mêmes de numéro de registre national.

Croiser des données personnelles avec le service de pseudonymisation à l’aveugle

Les trois inconvénients décrits dans le paragraphe précédent pourraient être résolus en utilisant dès à présent le service de pseudonymisation à l’aveugle.

Le scénario dans lequel toutes les sources de données conservent les données à caractère personnel sous le numéro de registre national est représenté dans l’illustration 4. Le flux entre un hôpital (data source) et Sciensano (collector) est exactement le même que celui de l’illustration 1, les trois propriétés de sécurité formulées précédemment étant évidemment maintenues :

• Les sources de données (data source, par exemple les hôpitaux) sont hypermétropes et ne voient donc que les numéros de registre national
• Le collector (par exemple Sciensano) est myope et ne voit donc que les pseudonymes spécifiques au projet
• Le service de pseudonymisation est aveugle et ne voit donc aucun des deux.

Si plusieurs sources de données fournissent des données sur le même citoyen, elles communiquent le même numéro de registre national au flux de pseudonymisation (ligne pleine), ce qui donne le même pseudonyme spécifique au projet du côté du collecteur. Cela permet au collecteur de relier les données sur le même citoyen provenant de différentes sources de données.

Illustration 4. Croisement et pseudonymisation de données provenant de différentes sources de données, qui stockent toutes des données à caractère personnel sous des numéros de registre national.

L’illustration 5 présente pour finir un scénario mixte, dans lequel au moins une source de données stocke des données à caractère personnel sous des numéros de registre nationaux et au moins une source de données stocke des données à caractère personnel sous des pseudonymes obtenus à l’aide du service de pseudonymisation à l’aveugle. Cette dernière source de données pourrait, par exemple, être le service interne de prescription de l’illustration 1.

Nous obtenons donc deux variantes du flux de pseudonymisation (ligne pleine) :

• Le service de pseudonymisation reçoit un pseudonyme en aveugle de la source de données A et effectue une opération convert (voir la section “L’opération convert“) pour obtenir un pseudonyme à l’aveugle spécifique au projet.
• Le service de pseudonymisation reçoit un numéro de registre national en aveugle de la source de données B et effectue une opération pseudonymise pour obtenir un pseudonyme à l’aveugle spécifique au projet.

Dans le cas où le pseudonyme que la source de données A a donné en entrée correspond au numéro de registre national que la source de données B a donné en entrée, il en résultera le même pseudonyme spécifique au projet chez Sciensano.

Dans le cas contraire, les deux flux sont identiques. Rien ne change ni pour les sources de données (par exemple, les institutions publiques) ni pour le collector (par exemple, Sciensano).  Le collector n’a même pas besoin de savoir si une source de données utilise des pseudonymes ou non.

Illustration 5. Croiser et pseudonymiser les données provenant de deux sources de données, l’une stockant les données à caractère personnel sous des numéros de registre national et l’autre sous des pseudonymes.

Les inconvénients de l’approche actuelle mentionnés précédemment sont supprimés :

• Le service de pseudonymisation ne voit ni les identifiants ni les pseudonymes et ne peut donc plus créer de profils. En outre, le fait d’effectuer plusieurs fois une opération en aveugle sur le même numéro de registre national (ou pseudonyme) donne lieu à une opération en aveugle différente à chaque fois. Le service de pseudonymisation ne peut donc pas non plus utiliser les identifiants ou les pseudonymes masqués pour relier les informations de profil.
• Le collector (par exemple Sciensano) reçoit toutes les informations provenant de la même source de données (par exemple, l’hôpital) par un seul canal direct.
• Nous pouvons traiter de manière particulièrement élégante les situations dans lesquelles une ou plusieurs sources de données utilisent déjà le service de pseudonymisation à l’aveugle.

Conclusion

Grâce au service de pseudonymisation à l’aveugle d’eHealth, nous pouvons élégamment et en toute sécurité croiser et pseudonymiser des données provenant de différentes sources de données à des fins de recherche.

En outre, un autre avantage est qu’aucune infrastructure supplémentaire n’est nécessaire ; beaucoup plus de prescriptions sont émises et traitées pendant la journée que pendant la nuit. Par conséquent, la capacité de pseudonymisation est largement excédentaire pendant la nuit. C’est donc le moment idéal pour réaliser de tels projets de croisement, qui ne sont pas critiques en termes de temps. Bien entendu, les missions critiques en termes de temps sont toujours prioritaires.

Pour chaque projet de croisement, le service de pseudonymisation utiliserait une clé différente, ce qui entraînerait l’impossibilité de relier les pseudonymes au niveau du collecteur ; il ne serait alors pas en mesure de relier les données relatives au même citoyen, mais provenant de projets différents, sur la base des pseudonymes. 

Si cela s’avère nécessaire, la réidentification est possible grâce à l’opération identify, mais uniquement avec l’autorisation et la coopération du service de pseudonymisation, ce qui permet d’éviter l’arbitraire et les abus. Ces demandes doivent également être enregistrées. Le service de pseudonymisation peut également, si nécessaire, retirer la clé de pseudonymisation à un moment convenu, rendant ainsi impossible toute réidentification par ce moyen.

Bien entendu, les opérations blind et unblind doivent être prévues dans le logiciel utilisé par les sources de données, tandis que du côté du collecteur, les opérations decrypt et verify context doivent être prévues. L’expérience montre que cette intégration se fait sans problème.

Il convient toutefois de noter que cette approche n’est utile que si toutes les sources de données peuvent déterminer de manière autonome quels enregistrements sont pertinents et lesquels ne le sont pas. Ce n’est pas toujours le cas, comme par exemple dans le projet de croisement des données approuvé pendant la délibération 20/020 du 14 janvier 2020, où la Fondation Registre du Cancer est le seul à pouvoir fournir des données sur les citoyens atteints de sclérose en plaques (SEP), mais ne peut pas savoir qui est atteint de SEP. Smals Research a également trouvé une solution efficace et flexible pour cela. Cette solution est accessible à tous, ce qui élimine la nécessité d’un service de pseudonymisation pour assurer la sécurité de la pseudonymisation. Cela dépasse toutefois le cadre de cet article.

Si notre solution ou d’autres solutions de pseudonymisation et de référencement croisé des données à caractère personnel vous intéressent, n’hésitez pas à nous contacter.

Cette contribution a été soumise par Kristof Verslype, cryptographe chez Smals Research. Elle a été rédigée en son nom propre et ne prend pas position au nom de Smals.

Image source: Pixabay

De nieuwe pseudonimiseringsdienst van eHealth biedt hoge veiligheidsgaranties en wordt momenteel ingezet om de privacy van de burger te beschermen onder meer bij de opslag en verwerking van elektronische voorschriften. Deze dienst leent zich daarnaast ook bijzonder goed voor het kruisen en pseudonimiseren van persoonsgegevens in het kader van onderzoeksprojecten. Dit artikel licht toe hoe dit conceptueel mogelijk zou zijn.

De blinde pseudonimiseringsdienst van eHealth

De blinde pseudonimiseringsdienst van eHealth werd reeds uitgebreid beschreven in een eerdere blogpost. We hernemen het scenario waarbij een huisarts (client) vraagt aan de voorschriften backend (owner) om een elektronisch voorschrift te registreren.

Figuur 1 toont de basisflow; de dokter (client) vraagt aan de pseudonimiseringsdienst om een identifier om te zetten in een pseudoniem. De dokter stuurt vervolgens het pseudoniem, samen met de voorschriftendata naar de voorschriften backend, die de voorschriftendata onder dit pseudoniem bewaart.

Figuur 1. Basisflow voor het scenario waarbij een arts (client) vraagt aan de voorschriften backend (owner) om een elektronisch voorschrift te registreren.

Om een hoog niveau van veiligheid te bereiken, zijn de volgende veiligheidseigenschappen cruciaal:

1. De client is verziend; ze ziet enkel globale identifers (rijksregisternummers).
2. De owner is bijziend; het ziet enkel de lokale identifiers (pseudoniemen).
3. De pseudonimiseringsdienst is blind; het ziet noch identifiers, nog pseudoniemen.

Figuur 2 illustreert hoe dit gerealiseerd wordt door een aantal stappen aan de flow uit Figuur 1 toe te voegen.

1. De veiligheidseigenschap blinde pseudonimiseringsdienst (3) wordt gerealiseerd m.b.v. de blind en unblind-operaties (paars). Het rijksregisternummer van de patient wordt geblindeerd, wat een kortstondige encryptie is met een sleutel die slechts eenmaal gebruikt wordt. De pseudonimiseringsdienst zet het geblindeerde rijksregisternummer om in een geblindeerd pseudoniem en ziet daarbij noch het originele rijksregisternummer, noch het resulterende pseudoniem (vergeet even de blauwe en oranje operaties; die bespreken we dadelijk). Enkel de client kan de blindering ongedaan maken m.b.v. de unblind-operatie.
2. In de basisflow in Figuur 1 komt de owner geen rijksregisternummers te weten, waardoor de veiligheidseigenschap bijziende owner (2) sowieso reeds gerealiseerd is.
3. Dankzij de encrypt- end decrypt-operaties (oranje) wordt, ten slotte, de veiligheidseigenschap verziende client (1) gerealiseerd; de pseudonimiseringsdienst encrypteert het geblindeerde pseudoniem, zodat enkel de owner kan decrypteren.

Ten slotte wordt ongeoorloofd hergebruik van de geëncrypteerde pseudoniemen – die de client bekomt na de unblind-operatie – vermeden doordat de pseudonimiseringsdienst met de add context-operatie (blauw) context-informatie aan het vercijferde pseudoniem toevoegt, zoals het moment van creatie. De owner zal deze informatie controleren m.b.v. de verify context-operatie (blauw) en aanvaardt enkel binnenkomende vercijferde pseudoniemen die recent gecreëerd zijn.

Figuur 2. High-security flow voor het scenario waarbij een arts (client) vraagt aan de voorschriften backend (owner) om een elektronisch voorschrift te registreren.

De convert-operatie

In voorgaande sectie paste de pseudonimiseringsdienst specifiek de pseudonymise-operatie toe om rijksregisternummers om te zetten in pseudoniemen. In bepaalde scenario’s is ook de inverse operatie vereist, met name de identify-operatie, waarbij een pseudoniem gekend door de owner terug omgezet wordt in het oorspronkelijke rijksregisternummer aan de kant van een client.

Systemen (owners) communiceren ook onderling met elkaar. Een dienst op het eHealth platform zou bijvoorbeeld kunnen vragen aan de TherLink service of een patiënt een therapeutische relatie heeft met een bepaalde arts. Indien TherLink ook met pseudoniemen werkt, zal een pseudoniem van de ene dienst/owner omgezet moeten worden naar het pseudoniem van de andere dienst/owner. Dit gebeurt met behulp van de convert-operatie. Om het identificatierisico zo klein mogelijk te houden is het immers aangewezen om dezelfde pseudoniemen niet over meerdere diensten te hergebruiken.

De drie operaties die de pseudonimiseringsdienst moet ondersteunen zijn dus pseudonymise, identify en convert. We zullen zien dat zowel de pseudonymise– als de convert– operaties nuttig zijn bij het kruisen en pseudonimiseren van persoonsgegevens. De identify laat ons dan weer toe om gecontroleerd burgers te identificeren. Dit kan in bepaalde situaties wenselijk zijn, bijvoorbeeld wanneer onderzoekers merken dat bepaalde burgers een wel erg hoog risico lopen op bepaalde aandoeningen, of misschien onbewust reeds hebben.

Kruisen van persoonsgegevens – de huidige aanpak

Voor onderzoeksdoeleinden worden geregeld persoonsgegevens afkomstig van verschillende bronnen gekruist en gepseudonimiseerd. Dat laatste is een noodzakelijke maatregel die helpt te verhinderen dat de onderzoeker persoonsgegevens kan koppelen aan natuurlijke personen.

Als concreet voorbeeld nemen we beraadslaging 13/093 van 22 oktober 2013, dat Sciensano toegang geeft tot medische data afkomstig van verschillende ziekenhuizen, met als doel inzichten te verkrijgen in de epidemiologie van patiënten met diabetes. Sciensano komt daarbij geen rijksregisternummers te weten, maar enkel pseudoniemen.

Figuur 3 toont – enigszins geabstraheerd – hoe dit tot op vandaag verloopt m.b.v. eHealth Batch Codage, een pseudonimiseringsdienst die al wat langer bestaat dan onze blinde pseudonimiseringsdienst. data^A_id is de data m.b.t. de burger met rijksregisternummer id die aangeleverd wordt door ziekenhuis A.

De ziekenhuizen sturen voor elke betrokken burger de gevraagde data rechtstreeks naar Sciensano en het rijksregisternummer naar eHealth Batch Codage. Die laatste zet het rijksregisternummer om naar een projectspecifiek pseudoniem pseudonym^link_id en stuurt dit pseudoniem naar Sciensano. Sciensano ontvangt dus data afkomstig van een ziekenhuis via het ene kanaal en pseudoniemen afkomstig van de Batch Codage via een ander kanaal. Dankzij een tijdelijk transit-pseudoniem (vb. nym^A_id), dat verborgen blijft voor Batch Codage, is Sciensano in staat om de data aan de projectspecifieke pseudoniemen te koppelen. Via die projectspecifieke pseudoniemen, ten slotte, is Sciensano in staat om data over dezelfde burger maar afkomstig van verschillende bronnen aan elkaar te koppelen.

Figuur 3. Kruisen en pseudonimiseren van persoonsgegevens afkomstig van meerdere ziekenhuizen, bestemd voor Sciensano, zoals beschreven in beraadslaging 13/093.

Deze aanpak heeft een aantal minpunten:

• Batch Codage moet vertrouwd worden. Het is een Trusted Third Party (TTP); het ziet zowel de binnenkomende rijksregisternummers als de buitengaande pseudoniemen. Het weet aan welk kruisingsproject het meewerkt en kan dus in theorie profielen per burger aanleggen; bijvoorbeeld weet het na twee projecten welke burgers zowel betrokken waren in zowel het onderzoek rond diabetes als het onderzoek rond Multiple Sclerose. Dergelijke profielen kunnen op termijn vrij veel gevoelige informatie bevatten.
• Twee communicatiekanalen. Sciensano moet in staat zijn om de data die het rechtstreeks ontvangt van de ziekehuizen te koppelen aan de pseudoniemen die het ontvangt van Batch Codage. Er is weliswaar een oplossing, maar het zou eleganter zijn indien alle informatie rechtstreeks van het ziekenhuis naar Sciensano gestuurd werd via één enkel kanaal.
• Slechte integratie bij gepseudonimiseerde input. Dit systeem kan niet op een elegante manier overweg met situaties waarbij één of meerdere databronnen reeds gebruik maken van de eerder beschreven blinde pseudonimiseringsdienst en dus zelf geen rijksregisternummers kennen.

Kruisen van persoonsgegevens met de blinde pseudonimiseringsdienst

De drie nadelen beschreven in de vorige sectie zouden verholpen kunnen worden door voortaan beroep te doen op de blinde pseudonimiseringsdienst.

Het scenario waarbij alle databronnen de persoonsgegevens bewaren onder het rijksregisternummer wordt geïllustreerd in Figuur 4. De flow van een ziekenhuis (databron) naar Sciensano (collector) is exact dezelfde flow als die in Figuur 1, waarbij de drie eerder geformuleerde veiligheidseigenschappen uiteraard behouden blijven:

• De databronnen (vb. ziekenhuizen) zijn verziend en zien dus enkel rijksregisternummers
• De collector (vb. Sciensano) is bijziend en ziet dus enkel project-specifieke pseudoniemen
• De peudonimiseringsdienst is blind en ziet dus geen van beiden.

Indien meerdere databronnen data aanleveren over eenzelfde burger, geven ze hetzelfde rijksregisternummer als input aan de pseudonimisatieflow (volle lijn), wat resulteert in eenzelfde projectspecifieke pseudoniem aan de kant van de collector. Dat laat de collector dan weer toe om data over eenzelfde burger, afkomstig van verschillende databronnen, aan elkaar te koppelen.

Figuur 4. Kruisen en pseudonimiseren van data afkomstig van verschillende databronnen, die allen persoonsgegevens bewaren onder rijksregisternummers

Figuur 5, ten slotte, illustreert een gemengd scenario, waarbij minstens één databron persoonsgegevens onder rijksregisternummers bewaart en minstens één databron persoonsgegevens bewaart onder pseudoniemen die m.b.v. de blinde pseudonimiseringsdienst bekomen werden. Die laatste databron zou bijvoorbeeld de prescription backend uit Figuur 1 kunnen zijn.

We krijgen dus twee varianten op de pseudonimiseringsflow (volle lijn):

• De pseudonimiseringsdienst ontvangt een geblindeerd pseudoniem van databron A en voert er een convert-operatie op uit (zie sectie “De convert-operatie“) wat resulteert in een geblindeerd projectspecifiek pseudoniem.
• De pseudonimiseringsdienst ontvang een geblindeerd rijksregisternummer van databron B en voert er een pseudonymise-operatie op uit wat eveneens resulteert in een geblindeerd projectspecifiek pseudoniem.

Indien het pseudoniem dat databron A als input gaf overeenkomt met het rijksregisternummer dat databron B als input gaf, zal dat resulteren in eenzelfde projectspecifiek pseudoniem bij Sciensano.

Voor de rest zijn beide flows identiek. Noch voor de databronnen (vb. publieke instellingen) noch voor de collector (vb. Sciensano) verandert er iets. De collector hoeft niet eens op de hoogte te zijn of een databron al dan niet met pseudoniemen werkt.

Figuur 5. Kruisen en pseudonimiseren van data afkomstig van twee databronnen, waarbij de ene databron persoonsgegevens bewaart onder rijksregisternummers en de andere onder pseudoniemen.

De eerder geformuleerde minpunten bij de huidige aanpak zijn bij deze van de baan:

• De pseudonimiseringsdienst ziet identifiers noch pseudoniemen en kan dus geen profielen meer aanleggen. Meerdere malen een blind-operatie uitvoeren op eenzelfde rijksregisternummer (of pseudoniem) resulteert bovendien telkens in een andere blindering. De pseudonimiseringsdienst kan dus evenmin geblindeerde identifiers of pseudoniemen gebruiken om profielinformatie aan te koppelen.
• De collector (vb. Sciensano) ontvangt alle informatie afkomstig van eenzelfde databron (vb. ziekenhuis) via één rechtstreeks kanaal.
• We kunnen op een bijzonder elegante manier overweg met situaties waarbij een of meerdere databronnen reeds gebruik maken van de blinde pseudonimiseringsdienst.

Conclusie

Dankzij de blinde pseudonimiseringsdienst van eHealth, kunnen we op een elegante en erg veilige wijze data afkomstig van verschillende databronnen kruisen en pseudonimiseren voor onderzoeksdoeleinden.

Een bijkomend voordeel is bovendien dat er geen bijkomende infrastructuur vereist is; overdag worden veel meer voorschriften uitgegeven en verwerkt dan ’s nachts. ’s Nachts is er bijgevolg heel wat pseudonimisatiecapaciteit op overschot. Dat is dan ook het ideale moment om dergelijke kruisingsprojecten, die niet tijdskritisch zijn, uit te voeren. Uiteraard krijgen tijdskritische opdrachten steeds voorrang.

Voor elk kruisingsproject zou de pseudonimiseringsdienst een andere sleutel gebruiken, wat resulteert in pseudoniem-onlinkbaarheid bij de collector; deze is dan niet in staat om gegevens over eenzelfde burger, maar uit verschillende projecten, aan elkaar te linken op basis van pseudoniemen. 

Mocht dit nodig zijn is met de identify-operatie heridentificatie mogelijk, maar enkel mits autorisatie en medewerking van de pseudonimiseringsdienst, wat willekeur en misbruik tegengaat. Dergelijke aanvragen dienen bovendien gelogd te worden. De pseudonimiseringsdienst kan ook – mocht dit vereist zijn – de pseudonimiseringssleutel op een afgesproken moment verwijderen, waardoor heridentificatie langs deze weg onmogelijk wordt.

Uiteraard moet de blind– en unblind-operatie voorzien worden in de software die de databronnen gebruiken, terwijl aan de kant van de collector de decrypt– en verify context-operaties voorzien moeten worden. De ervaring leert ons dat deze integratie vrij vlot verloopt.

Bemerk wel dat deze aanpak enkel nuttig is indien alle databronnen autonoom kunnen bepalen welke records relevant zijn en welke niet. Dit is niet steeds het geval, zoals bijvoorbeeld in het datakruisingsproject dat goedgekeurd werd met beraadslaging 20/002 van 14 januari 2020, waarbij het Belgisch Kankerregister enkel data mag aanleveren over burgers met Multiple Sclerose (MS), maar zelf niet te weten mag komen wie MS heeft. Ook daarvoor heeft Smals Research een efficiënte en flexibele oplossing bedacht. Die oplossing is bovendien gedistribueerd, waardoor niet langer een pseudonimiseringsdienst nodig is om veilig te pseudonimiseren. Dit valt echter buiten de scope van dit artikel.

Aarzel niet ons te contacteren bij interesse in onze oplossingen voor het pseudonimiseren en kruisen van persoonsgegevens.

Dit is een ingezonden bijdrage van Kristof Verslype, cryptograaf bij Smals Research. Het werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Image source: Pixabay

De GDPR vermeldt nadrukkelijk pseudonimisatie als maatregel om persoonsgegevens te beschermen, wat tevens past in het privacy by design principe dat in diezelfde verordening gepromoot wordt. In artikel 32 lezen we er bijvoorbeeld:

“Rekening houdend met de stand van de techniek, de uitvoeringskosten, alsook met de aard, de omvang, de context en de verwerkingsdoeleinden en de qua waarschijnlijkheid en ernst uiteenlopende risico’s voor de rechten en vrijheden van personen, treffen de verwerkingsverantwoordelijke en de verwerker passende technische en organisatorische maatregelen om een op het risico afgestemd beveiligingsniveau te waarborgen, die, waar passend, onder meer het volgende omvatten: a)  de pseudonimisering en versleuteling van persoonsgegevens b) …

en in artikel 89:

“De verwerking met het oog op archivering in het algemeen belang, wetenschappelijk of historisch onderzoek of statistische doeleinden is onderworpen aan passende waarborgen in overeenstemming met deze verordening voor de rechten en vrijheden van de betrokkene. Die waarborgen zorgen ervoor dat er technische en organisatorische maatregelen zijn getroffen om de inachtneming van het beginsel van minimale gegevensverwerking te garanderen. Deze maatregelen kunnen pseudonimisering omvatten, mits aldus die doeleinden in kwestie kunnen worden verwezenlijkt. Wanneer die doeleinden kunnen worden verwezenlijkt door verdere verwerking die de identificatie van betrokkenen niet of niet langer toelaat, moeten zij aldus worden verwezenlijkt. …”

Pseudonimisatie impliceert dat persoonsgegevens niet langer rechtstreeks d.m.v. een identificatiesleutel zoals het rijksregister gekoppeld kunnen worden aan een natuurlijk persoon, maar enkel m.b.v. additionele informatie die elders bewaard wordt. Gepseudonimiseerde persoonsgegevens zijn een nieuwe categorie gegevens in de privacywetgeving.

Het idee van pseudonimisatie is dat eenzelfde burger in elke context slechts gekend is onder het context-specifieke pseudoniem. Persoonsgegevens uit de ene context zijn dus niet zomaar te koppelen aan gegevens over dezelfde persoon in een andere context of aan de natuurlijke persoon zelf. Dit maakt misbruik een pak moeilijker. Een context kan echter heel wat betekenen, zoals blijkt uit onderstaande voorbeelden.

• Online leerplatformen. Scholen maken in toenemende mate gebruik van online leerplatformen, waar de leerlingen allerlei materiaal ter beschikking krijgen en ook huiswerk maken en testen afleggen. Deze data kan commercieel erg waardevol zijn voor zowel de aanbieder van het platform als voor hackers, zeker als het te koppelen is aan andere informatie van die scholier. Mogelijks bevat het profiel van de leerling medische – en dus gevoelige – informatie; Een leerling kan bijvoorbeeld meer tijd krijgen voor een online test omwille van dyslexie.
  De school moet de leerling natuurlijk wel kunnen identificeren, maar er is geen enkele reden dat ook het online platform dit zou moeten kunnen. We willen niet dat eenzelfde platform over de jaren en vakken heen een erg uitgebreid profiel aan eenzelfde leerling kan koppelen. Per jaar en per vak zou een leerling door het platform slechts gekend kunnen zijn onder een apart pseudoniem, terwijl slechts de school in staat is pseudoniemen van eenzelfde scholier aan elkaar te koppelen. De context is hier dus een vak tijdens een bepaald schooljaar.
• Wetenschappelijke onderzoek. Geregeld is er in het kader van een specifiek wetenschappelijke onderzoek nood aan een – rijk of minder rijk – gegevensbestand met bijvoorbeeld specifieke medische gegevens van bepaalde burgers. Een context komt hier overeen met een specifiek onderzoek. Zelfs indien de wetenschappers (of hackers) zouden willen, zijn ze niet in staat op basis van het pseudoniem gegevens van eenzelfde persoon aan elkaar of aan publiek beschikbare gegevens over die burger te koppelen.
• Data warehouse.  Zowat elke overheidsinstelling beheert een specifieke set burgergegevens, wat onder meer kan gaan over pensioen-, medische, professionele of fiscale gegevens.  Echter, om zinvolle analyses te kunnen doen moeten vaak gegevens afkomstig van meerdere bronnen – zoals overheidsinstellingen en medische sensoren – gekruist (gecombineerd) worden.  Om praktische redenen zou geopteerd kunnen worden voor een data warehouse dat alle persoonsgegevens bevat die eventueel ter beschikking gesteld kunnen worden voor analyses of wetenschappelijk onderzoek (zie vorig puntje). Een wetenschapper krijgt dan uiteraard enkel toegang tot die gegevens die strikt noodzakelijk zijn voor het onderzoek in kwestie. Maar indien in dit data warehouse alle gegevens van eenzelfde burger triviaal aan elkaar en aan een natuurlijk persoon gekoppeld kunnen worden – bijvoorbeeld m.b.v. het rijksregisternummer -, ontstaat uiteraard een onaanvaardbaar groot privacyrisico. Daarom zou geopteerd kunnen worden om de gegevens van eenzelfde burger te verspreiden over heel wat verschillende compartimenten in het data warehouse. In het ene compartiment kunnen fiscale gegevens bewaard worden, in een ander basisgegevens zoals geboortedatum, geslacht en woonplaats. Op elk van die compartimenten is eenzelfde burger gekend onder een ander pseudoniem. Slechts wanneer de organisaties en bedrijven die de data aanleveren meewerken, kunnen bepaalde gegevens gekoppeld worden. Elk compartiment is een afzonderlijke context. Het profiel van een burger wordt dus in heel wat stukjes gebroken, die quasi onmogelijk in elkaar gepast kunnen worden door onbevoegden. Bovendien zijn kleinere stukjes sowieso moeilijker aan een natuurlijk persoon te koppelen dan grotere stukken data.

Bovenstaande toepassingen in de praktijk brengen zal al snel vrij omslachtig worden wanneer gebruik gemaakt wordt van traditionele pseudonimisatietechnieken, dus op basis van willekeurig gegenereerde pseudoniemen, cryptografische hashing of (symmetrische of asymmetrische) cryptografische vercijfering. Daarom wordt het best gekeken naar meer geavanceerde cryptografische pseudoniemistatietechnieken. Deze technieken zijn vrij jong en vandaag nog te weinig gekend, maar maken een onwaarschijnlijke flexibiliteit en bescherming mogelijk.

Smals Research was in 2015 een van de eersten die een dergelijk cryptografische pseudonimiseringssysteem ontwikkelde en succesvol toepaste in een proof of concept. Ondertussen publiceerden onder meer de Radboud Universiteit van Nijmegen en het onderzoekslab van IBM in Zürich reeds erg waardevolle bijdragen, de eerste op een meer praktisch, de tweede op een meer theoretisch niveau.

Het idee dat telkens terugkomt is dat een natuurlijke persoon in elke context gekend is onder een ander pseudoniem. Met een geheime sleutel worden rijksregisternummers omgezet in pseudoniemen, die eventueel op hun beurt weer omgezet kunnen worden in andere pseudoniemen. De operatie kan dus transitief zijn. Twee verschillende pseudoniemen van eenzelfde persoon kunnen eventueel met de juiste sleutels na hun respectievelijke converties resulteren in één en hetzelfde pseudoniem. Daardoor kan de bijhorende data onder bepaalde condities aan elkaar gekoppeld worden zonder te weten over welke natuurlijke persoon het gaat. Eventueel kan een derde partij een pseudoniem onder bepaalde voorwaarden, bijvoorbeeld na akkoord van de gegevensbeschermingsautoriteit, opnieuw koppelen aan het oorspronkelijke rijksregisternummer. Bovendien kunnen dergelijke systemen transparantie bieden aan – en enkel aan – de betrokken burger. (Ter volledigheid geven we mee dat niet elk pseudoniemsysteem alle in deze paragraaf beschreven eigenschappen bezit.)

De Radboud universiteit heeft i.s.m. de Nederlandse provincie Gelderland reeds een onderzoeksproject opgezet met een budget van 1,6 miljoen euro. Het project gaat specifiek over het op een privacy-vriendelijke wijze uitwisselen van medische gegevens voor onderzoeksdoeleinden. Er werd reeds succesvol een concrete piloot opgezet, waarbij 650 Parkinson-patiënten over een periode van 2 jaar gevolgd worden en waarbij allerlei gegevens aangeleverd worden door draagbare toestellen (wearable devices). Bovendien zou  hun pseudoniem- en encryptiesysteem ondersteund worden door de toekomstige Nederlandse eID kaart.

In al de bovenstaande voorbeelden heeft de betrokken burger geen controle over wat er met zijn rijksregister en pseudoniemen gebeurt. Er zijn echter andere systemen – Attribute-based credentials – waarbij de pseudoniemen onder de controle van de burger zelf blijven. De burger kan dan zelf beslissen om zich tegenover verschillende entiteiten kenbaar te maken onder verschillende, onlinkbare pseudoniemen, eventueel gekoppeld aan bepaalde gecertifieerde persoonsgegevens zoals leeftijd. Hier zal in een toekomstige blogpost dieper op ingegaan worden.

Samengevat bieden cryptografische pseudoniemen een krachtig instrument om persoonsgegevens, en daarmee ook de privacy van de betrokkenen, beter te beveiligen. Het is dan ook niet enkel een nuttig, maar op termijn noodzakelijk instrument om toepassingen in overeenstemming te brengen met de GDPR.

Aarzel niet ons te contacteren om toepassingen binnen de context van de overheid in België te bespreken!

Dit is een ingezonden bijdrage van Kristof Verslype, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Introduction

We focus on the following situation. What if a research team wants to analyse large sets of personal data? Say it needs medical, financial and demographic data of all citizens with a wage of at least € 40.000, born in or after 1990 and who are self-employed as a secondary activity. Data sets managed by different government organizations would need to be linked together. Such requests are common, and any government should be able to answer them. Yet is it possible with due respect for the privacy of citizens in an era of big data?

Before answering this question, let’s first clarify the distinction between the three categories of data defined in the GDPR: Anonymous data, identified data and the new category, pseudonymous data.

• Anonymous data can impossibly be linked to a natural person. An example are statistical medical data. The GDPR is not applicable on anonymous data.
• Identified data are linkable to a natural person without additional information. An example are medical records that contain the citizen’s social security number. The GDPR fully applies on identified data.
• Pseudonymous data is linkable to a natural person, but only with extra information that is stored elsewhere. An example are medical records where the citizen’s social security number is replaced by a unique code. The mapping between these codes and the citizens’ social security numbers is stored separately. The GDPR still applies, but some provisions are relaxed. The GDPR encourages the use of pseudonymous data.

By replacing identifiers by pseudonyms, we convert identified data into pseudonymous data. However, completely removing the identifiers does not necessarily result in anonymous data and should in many cases still be considered as pseudonymous data. Imagine, for instance, that the medical records contain the social security number, the gender, date of birth, the ZIP code and some medical data, such as the disease the citizen is suffering from. Imagine that only the identifiers are removed. If Bob knows the date of birth, gender and ZIP code of Alice, he is often able to link this de-identified medical record uniquely to Alice, and is, hence, able to learn sensitive medical data about her.

In a traditional approach, the data-delivering government organizations send the required data on a regular basis to a central data warehouse that stores the personal data. Data of the same citizen are trivially linkable to each other. If a research team wants to analyse data, it receives a pseudonymized subset of the data. Although linking of data originating from different sources becomes trivial, the approach comes with several risks:

• The data-delivering government organizations lose all control over the personal data for which they are still legally accountable. These government organizations have, as data controllers, indeed still responsibilities and duties according to the GDPR. How is it sure that the data are not used for purposes incompatible with the purpose for which they have been initially collected?
• In case of a data breach of the data warehouse, the consequences are dramatic, not only for the institution managing the data warehouse, but also for the millions of citizens whose privacy is severely affected. We see indeed that hacking attempts become increasingly professional and that the amount of personal data amassed by organizations and companies explodes. Both aspects contribute to the increase in risk.
• Even when pseudonimized, the data entrusted to the research team generally remain sensitive. If these data are stolen or made public, the consequences for citizens’ privacy can still be considerable.

Can we do better? Can we use technology to reduce these risks? How well can we protect personal data by using cryptographic pseudonyms? By answering these questions, we also shed light on what future analysis on personal data originating from multiple sources might look like.

The Data Archipelago – Central Ideas

The core idea is to have, instead of one big data warehouse, several ‘data islands‘ which are maximally isolated. As illustrated in the figure below, we distinguish between the long-term domain islands, with strong isolation, and the short-term project islands, with a somewhat weaker isolation.

Domain islands. Each data-providing organization controls its own domain island (or islands) and keeps the contained data up-to-date. It only uploads these personal data to the domain islands that might be made available for data analysis projects. The data in the domain island is, hence, a subset of all the personal data controlled by the government organization. We use two principles to maintain perfect isolation between domain islands:

1. Island-specific pseudonyms, instead of identifiers, are used for personal data on the domain islands. Different domain islands use a different, unlinkable pseudonym for the same citizen. Only after a procedure in which the involved government organizations give their consent with a secret cryptographic key, data about the same citizen can be linked together, without revealing any identifiers (see later).
2. Attribute partitions. There is no overlap between the attributes stored by the domain islands. If domain island A stores your gender, no other domain island will contain it. Hence, If an entity has access to multiple islands, (s)he will be unable to link any of the records to each other based on attributes.

Hence, an attacker cannot know whether a record in domain island A and another record in domain island B belong to the same citizen. Only with the proper cryptographic keys, which are controlled and kept secret by the data-providing government organizations, it is possible to do this linking.

Domain islands can be stored in the central data warehouse, or on infrastructure of the controlling government institution. However, the data warehouse should be able to communicate with the domain islands.

Project islands. For each approved project, personal data originating from different domain islands are selectively linked together and stored on a project island. The project island only contains relevant attributes of the involved citizens. The lifetime of a project island is restricted to the duration of the project. Also, the project islands stay under the exclusive control of the data warehouse. Researchers are allowed to do certain data queries on the project island, but are never allowed to have full access to the raw data. Hence, we bring the calculations to the data instead of the data to the calculations.

Also, for the project islands, isolation is maximized, although at a lower level than the domain islands. We again apply the concept of island-specific pseudonyms. For each (domain or project) island, the same citizen is known under a different pseudonym. Note, however, that based on shared attributes, it might be possible to link records on a project island to other (domain or project) islands. Therefore, it is still important to sufficiently protect the project islands and minimize not only their lifetime, but also the data they store. Maybe the project does not need the exact date of birth, but just an age category.

By applying this approach, we arrive at the situation shown in the figure below. Although records of the same citizen are known by organizations under the same social security number, the citizen’s personal data are known under a different pseudonym on each island.

This results in the following properties:

• Maximal control by organizations. We give the data-delivering government organizations full control over what happens with their data. They receive a description of the new analysis project and only if it is compatible with the purposes for which it has originally been collected, the data is delivered to the project.
• Smaller impact in case of data breach & better privacy. In case a hacker has access to data in several islands, or in case data are leaked into the public, the damage is limited. Data on the permanent domain islands are in any case unlinkable. The linkability of data on project islands is minimized, by the use of project-specific pseudonyms and by limiting the data on and the lifetime of project islands. This way, we maximize the isolation between the islands, and, hence, the privacy of the citizens. Indeed, the more data of the same citizen you can link, the easier it becomes to identify this person.

Linking records with cryptography

The use of cryptographic keys is sketched in the figure below. Organizations and islands have keys, which are used to convert identifiers into pseudonyms or pseudonyms into other pseudonyms. Pseudonym conversion is indicated by a dashed line near the corresponding key.

Each organization has a master key, each domain island has a key per project that it delivers data to, and each project island has one key per domain that it receives data from.

All government organizations in Belgium use the same social security number to identify a citizen. Using their master key, they convert it into a pseudonym that is used on the level of the domain island. Each government institution has its own master key. The same social security number converted with two different master keys results in two different, without the cryptographic keys unlinkable, domain pseudonyms. A subset of the data controlled by the data-providing government organization is sent to the domain island, whereby the social security numbers are replaced by these pseudonyms.

When a project is created, the involved domain islands each obtain a project-specific key, and the project island obtains a domain-specific key per involved domain island. Domain pseudonyms are converted with the project-specific key into unique transfer pseudonyms. When these transfer pseudonyms are received by the project island, they are converted with the domain-specific key into a project pseudonym. The transfer pseudonyms are deleted after the data transfer. Once all data is delivered by the domain islands to the project island, the associated keys in the project and the islands should be removed. The government organizations should, however, maintain their master keys.

By properly choosing the keys in the system, the following properties are achieved:

• Different domain pseudonyms corresponding to the same citizen are always converted into the same project pseudonym. Hence, different, unlinkable pseudonimized records of personal data received from different domain islands become again linkable on the project island.
• Domain pseudonyms of different citizens are converted into different project pseudonyms on the same project island.
• The same citizen is known under different, unlinkable pseudonyms on different project islands

In summary, a citizen is known under a different, unlinkable pseudonym on each island that contains personal data about him or her.

An example to illustrate the protocol

Let’s have a look at the example described in the introduction. A research team wants to analyse large sets of personal data. Say it needs medical, financial and demographic data of all citizens with a wage of at least EURO 40.000, born after 1990 and who are self-employed as a secondary activity. For the moment, we restrict our example to three domain islands and assume that the required personal data are stored in the second and third domain island:

• The first is the domain island of the National Register (Rijksregister) which contains for each citizen data about date of birth, gender, place of residence, nationality, etc.
• The second, the RSVZ island, contains data about independents in Belgium, and, hence, knows who is self-employed as secondary activity.
• The third one, the RSZ island, has the data about employees, and, hence knows the wage of each citizen.

In order to obtain the required data, the following steps, illustrated in the four pictures below, are performed:

1. The project island asks each of the involved domain islands for the relevant pseudonyms. It asks the domain island of the National Register to provide the pseudonyms of all citizens that are born in or after 1990, it asks the RSVZ island to provide pseudonyms of all citizens who are self-employed as secondary activity and it asks the RSZ island for the pseudonyms of citizens who have a salary of at least 40 000 €.
2. Each of the involved islands retrieves locally the relevant domain pseudonyms, converts them into transfer pseudonyms and sends them to the project island. The project island converts each of the received transfer pseudonyms with the proper key into project pseudonyms. For each involved domain island, the project island now has a separate set of project pseudonyms.
3. The project island now takes the intersection of the three pseudonym sets, resulting in the set of project pseudonyms of the citizens of which the project islands needs data.
4. For each domain island of which data are needed, these pseudonyms are again converted into transfer pseudonyms, sent to the domain island, which converts the transfer pseudonyms back into domain pseudonyms.
5. The domain islands now select for each of the resulting domain pseudonym the relevant data and sends for each of the pseudonyms the relevant data to the project island. Again, the domain pseudonyms are converted into transfer pseudonyms by the domain islands before the data is sent to the project island
6. Upon receipt of the data records, the transfer pseudonyms are again converted into project pseudonyms. Each received data record now has a project pseudonym. If and only if two data records have the same project pseudonym, they belong to the same citizen and they can be trivially linked.

The six steps in the protocol to link data in a project island. A dashed line above a key indicates a cryptographic pseudonym conversion. Click on the figures to enlarge.

Step 1	Step 2
Steps 3 and 4	Steps 5 and 6

In case data needs to be retrieved from other domain islands, besides the ones of the RSVZ and the RSZ, steps 4,5 and 6 are also executed between the project island and each involved domain island. This way, the project island can also obtain, for instance, medical data.

The proposed approach ensures that the data-providing government organizations maintain maximal control over what happens with the data, since they control the cryptographic keys of their domain islands. The approach also ensures that the domain island does not learn more personal data than strictly necessary.

The presented approach, however, has some drawbacks.

• Personal data leaks to the domain islands. In our example, the RSVZ island learns that the pseudonyms received in step 4 belong to people born in 1990 or later with a salary of over 40 000 €. Similarly, the RSZ learns new personal information.
• The project island can ask too much data from the domain islands. In step 4, the domain islands cannot know whether the received pseudonyms belong effectively to the intersection calculated in step 3. This enables the project island to request also data about pseudonyms that are not in the intersection.

Both drawbacks can be prevented. We refer to our detailed report for more details.

Conclusions

In this article, we sketched the main ideas of the Data Archipelago, which we invented three years ago. Since then the concept has only gained importance, especially given the upcoming GDPR. Indeed, this European regulation encourages the use of privacy by design, which is exactly what we did here, as well as the use of pseudonyms. We presented a very specific case, linking together personal data for data analysis purposes, but we are convinced that the use of cryptographic pseudonyms can and should also be applied in many other contexts to better protect the privacy of citizens. In that respect, in the meantime we also came up with a blockchain based prescription processing scheme, that uses one-time pseudonyms to protect not only the privacy of the involved citizens, but also the confidentiality of business information. Unfortunately, the use of cryptographic pseudonyms is less straightforward than traditional approaches, which poses to European governments the challenge of obtaining and developing the right competences.

Several aspects have not been discussed in this introductory article. We didn’t talk about key generation, re-identification in case of fraud, or less straightforward combinations such as family configurations. We emphasize that for each of these aspects, we have come up with solutions.

Further information

• The content of this article was presented at InfoSecurity Brussels on 25 March 2017. The slides can be downloaded here.
• We wrote a scientific document were everything is described in detail.
• We also published a more accessible report in Dutch.

If you have questions or suggestions regarding our approach, feel free to contact us.