General description

Our health is precious. And our personal health data is among the most precious information. So we need to protect it! Smals – the main IT provider for the Belgian public sector – already had strong security measures in place, such as firewalls, hardware security modules, SIEM systems and database encryption. Yet we do more.

eHealth’s blinded pseudonymization service (Intro in Dutch or French) adds an extra layer of security. It enables Smals to manage for example electronic prescriptions without ever learning to whom they belong, without knowing the social security number. Instead, Smals only sees unique codes (pseudonyms). Even if leaked, a hacker won’t be able to do much with the data.

The blinded pseudonymization service – managed by the Belgian eHealth-platform – ensures that only an authorized health care professional, such as your GP, can link a prescription to you. It’s blind, because it doesn’t see any pseudonyms or social security numbers.

We can’t simply encrypt all the data before sending it to the backend, because the latter has functional responsibilities, such as input validation and generation of statistics. Our approach enables the selective encryption of some of the data fields (e.g., free text by the GP), such that the backend only has access to the data it needs in order to fulfil its assigned tasks, without ever seeing social security numbers.

This elegant and versatile approach greatly reduces identification risks in case unauthorized (internal or external) entities obtain access to centrally stored medical data. This approach is the default choice for new e-health applications in Belgium. It is already in use today for electronic prescriptions and information about vaccines, prosthetic devices, fertility, allergies and intolerances. The latest application to use this service is TRIO to assist disabled persons. It is a successful example of privacy by design in the Belgian public sector.

Can you briefly describe the solution, product, technology, approach, or project?

The Belgian eHealth ecosystem consists of multiple backend services which store different types of medical data. Some examples are prescriptions, vaccinations and therapeutic relations. These backend services are contacted by citizens, health care professionals and other eHealth backend services. While Smals manages the backend services, eHealth manages security services (e.g. access control).

On top of the existing security measures, we introduced a new security layer guaranteeing that social security numbers are no longer exposed to backend services or their underlying infrastructure. The blinded pseudonymization service, managed by eHealth, was introduced.

The solution cryptographically guarantees that:

• Backend services learn backend-specific pseudonyms, but never social security numbers.
• Authorized health care providers (such as your GP) learn social security numbers, but never pseudonyms.
• The pseudonymisation service learns neither.

Hence, each party only learns the strictly minimal identifier-related information it needs to know.

The system is versatile; It also enables selective encryption to ensure that the backend service only sees the minimal required personal (yet pseudonymized) medical data to fulfil its responsibilities. Additionally, our approach enables to flexibly and securely pseudonymize and join (intro in NL and FR) data originating from different sources for scientific purposes (e.g. epidemiology) by research institutes (such as Sciensano in Belgium).

Can you demonstrate its innovative character?

Storing the unencrypted data and the social security number in databases is a bad yet common practice. Unauthorized access could have detrimental consequences.

Experience taught us that full encryption of all data by the client, and storage of the resulting ciphertexts by the backend under the unencrypted social security number, comes with serious functional limitations. The backend could indeed no longer validate the correctness of incoming values (e.g. medication codes) or extract statistics.

Therefore, we need a finer-grained approach that hides social security numbers as well as some of the medical data (e.g. free text written by the doctor).

Adjacent academic work exists. Notably, there is the polymorphic encryption and pseudonymization by Verheul et. al. While this pseudonymization service is located between the health care professional and the backend service, ours sits at the sideline. Consequently, our solution respects existing communication flows. Moreover, in contrast to the solution proposed by Verheul, the blinded pseudonymization service is unable to convert pseudonyms or ciphertexts into something decryptable by unauthorized entities. In summary, our service is less intrusive and requires less trust.

Springer Nature accepted in its 2025 volume Public Governance and Emerging Technologies our chapter discussing the blinded pseudonymisation service.

What is the added value of this security innovation in terms of security: how resilient and protective is it?

Security & Privacy

The solution greatly reduces the identification risk in case of an internal adversary (administrator) or external adversary (hacker) having access to or publishing the medical data stored by the backend service. The social security numbers, as well as a subset of the actual medical data in each separate record, remain hidden. It enables Smals to implement the principle that it should nowhere in the process have access to social security numbers. It is adopted as the default approach for new IT projects in Belgian healthcare and social security.

Our solutions greatly reduce identification risks, but does not reduce them to zero. It should be seen as an extra – but strong – layer of security, on top of the existing ones (such as access control, database encryption and firewalls).

High availability

The high availability of the pseudonymization service is guaranteed by the deployment of multiple instances and HSMs in multiple datacenters. Moreover, a backup solution is foreseen, offering limited functionality when the pseudonymization service is unavailable.

Correctness

The correctness of our solution has been validated by academic partners.

This is a submitted contribution by Kristof Verslype, cryptographer at Smals Research. It was written in his own name and does not take a position on behalf of Smals.

Featured image by Cybersec Europe

Hoewel dit op het eerste gezicht dramatisch lijkt, is dit in de praktijk niet het geval omdat “tijd” een verschillende betekenis heeft in business context dan in IT context. Bekijken we het voorbeeld van een patiënt die een elektronisch voorschrift krijgt bij de dokter, en dan naar de apotheker gaat om zijn “bestelling” op te halen:

Hoewel 10 seconden in computertermen een eeuwigheid is, is dat in business context niet.   De kans dat een patiënt binnen 40 seconden na het voorschrijven, de dokter kan betalen en bij de apotheker geraakt is quasi-onbestaande.

Het CAP theorema stelt bij dit voorbeeld dan ook geen problemen.  Deze deadlock situatie kan alleen opgelost worden door de business mee te betrekken. Om deze reden is het essentieel om High Availability reeds vanaf de requirements analyse in rekening te brengen.

De noodzakelijke evolutie naar “distributed systems”

Het CAP theorema zou omzeild kunnen worden (in theorie althans) door te evolueren naar één monolithisch systeem. Dit is echter geen oplossing omdat men dan het probleem verschuift naar binnen de grenzen van dit systeem.  In de moderne wereld waarbij online toepassingen door steeds meer mensen gebruikt worden, kan de nodige performantie immers vaak niet eens door één systeem geleverd worden.  Het lijkt er dus op dat we dus noodzakelijkerwijs evolueren naar gedistribueerde systemen. Redundantie is in dat geval een erg efficiënte manier om de beschikbaarheid te verhogen.

Availability tijdens de requirements analyse

Het CAP theorema zal het ons dus moeilijk maken! Zoals reeds gezegd, kan men in de praktijk echter veel verbeteren door High Availability reeds vanaf de requirements analyse in rekening te brengen door:

• de levensduur en vluchtigheid van de gegevens in kaart te brengen (de 40s in bovenstaand voorbeeld) en
• de eisen op vlak van beschikbaarheid te specificeren voor elke use-case in plaats van voor het volledige systeem.

Tijdens de architectuurfase kan men dan specifiek optimiseren naar deze niet-functionele beschikbaarheidsbehoeftes.

Beter vele kleintjes dan een paar grote

Het punt dat ik wil maken in deze post, is dat bij een redundante architectuur, de strategie van vele kleintjes vaak beter is dan een paar grote.  Bij een traditioneel actief-passief failover systeem behandelt één systeem alle aanvragen tenzij dit systeem uitvalt, waarbij het passief systeem actief wordt en haar taken overneemt.  In dit geval bevat elk apart deelsysteem de mogelijkheid om het volledige probleem “op te lossen” en het falen van een systeem is intrinsiek een incident.

Stel daarentegen een gedistribueerd systeem voor waarbij 10 kleine, goedkope servers elk een deel van de taak op zich nemen en hierover voortdurend met elkaar communiceren.  Als er eentje uitvalt, zijn er nog 9 beschikbaar om de taken te herverdelen (de performantie zal wel wat afnemen).  Door de architectuur hierop ingesteld is, integreert een nieuw opgestart deelsysteem zich automatisch in het geheel.  Het vervangen van zo’n deel-systeem wordt een standaard, dagdagelijkse onderhoudstaak, juist zoals het nemen van een backup.

WC papier?

De vergelijking die ik graag wil maken is het onderhoud van WC papier.  Laten we twee situaties vergelijken:

• er is één rol van 400 vellen geïnstalleerd
• er zijn vier rollen van elk 100 vellen geïnstalleerd

Elke dag nagekeken wordt of de rol op is.  Indien nodig wordt de rol vervangen.  Bekijken we de grafiek van de hoeveelheid beschikbare wc papier in functie van de tijd:

Zoals duidelijk op te maken valt uit dit simpele conceptuele voorbeeld, is er steeds WC papier beschikbaar indien men kiest voor kleinere deelsystemen. In de situatie waarbij men één rol van 400 vellen heeft, moet men ofwel kiezen voor “waste” (weggooien van wc papier) of voor “downtime” (de afwezigheid van wc-papier).  Deze conclusies kunnen formeel geabstraheerd worden naar andere systemen.

Maar nu moet ik nog even mijn handen wassen…