Anonymisation and traceability of data in a population health database
How we turned manual anonymisation into a standardised, reproducible and traceable process for the Servicio Navarro de Salud-Osasunbidea, the regional health service of Navarre
Removing the name and national ID number is not enough to anonymise data
SNS-O's Servicio de Evaluación y Difusión de Resultados en Salud, its health outcomes evaluation and dissemination service, disseminates data from Bardena, the population database that covers almost 97% of the population of Navarre. Anonymisation followed no formalised criteria, and once a dataset had been delivered there was no way to trace its source.
The Service extracts, processes and disseminates health data for research, management and publication. Until now, each extract was anonymised manually or semi-automatically, case by case, with no common framework to ensure consistency between deliveries and no verifiable protection thresholds.
On top of that unformalised anonymisation there was a more fundamental limitation: if a delivered dataset ended up leaked or misused, the Service had no mechanism for identifying its source. The engagement asked for three things at once—safe, consistent anonymisation, lower re-identification risk and reverse traceability—and for all of it to be compatible with the existing infrastructure and with the OMOP CDM model being adopted. The study is part of Spain's National Health Data Space (Espacio Nacional de Datos de Salud), under Component 18 of the Recovery, Transformation and Resilience Plan (PRTR), funded by Next Generation EU.
4
Functional R modules, from pseudonymisation to forensic verification
410
Automated tests that verify how the prototype behaves
17
Demonstration scenarios on a synthetic population
A framework built for the real system, not a generic template
Tailored anonymisation protocol
Before prescribing anything, we assessed the failure modes of the existing process so that the protocol would fit the Service's real needs, instead of applying a standard template. The result classifies each request by its use and granularity, and uses decision trees to prescribe the techniques and thresholds that apply to it: k-anonymity, l-diversity, differential privacy for publishable aggregates and per-instance pseudonymisation. The protocol sets a pre-delivery check that blocks anything that does not meet the thresholds.
Reverse traceability system
We designed a system that watermarks each delivery invisibly and uniquely for each recipient, combining several complementary techniques on the tabular data. The watermarking is designed to minimise its impact on legitimate analytical use and is validated through documented scenarios. If a dataset is leaked, the system makes it possible to identify its source, with a verification procedure and a digital chain of custody that keep the attribution documented, traceable and reproducible.
Validated working prototype
We implemented both protocols in an R package with four modules, from per-instance pseudonymisation to forensic verification of the source. As the Service could not provide access to real data, we built a synthetic population designed to reproduce the structures needed to validate the prototype, and demonstrated it in seventeen scenarios documented in a web report. It is a configurable prototype for the Service to adapt and integrate, delivered as added value beyond what was requested.
From anonymisation that only strips identifiers to protection against data linkage
Standardised, reproducible anonymisation
Case-by-case judgement gives way to a protocol with categories, decision trees and verifiable thresholds. The same request receives the same treatment regardless of who handles it, and every delivery is logged and reproducible.
The ability to attribute the source of a leak
The Service goes from being unable to trace a leaked delivery to having a reverse traceability system that documents the source of each dataset in a traceable, reproducible way. When the same extract has gone to several recipients, it can determine which of them a dataset came from.
A roadmap built on what they already have
The study closes with an implementation plan over three horizons, designed around the software and hardware the Service already owns, with minimal need for new purchases. The first stage, low-cost and high-impact, is within immediate reach.
What this case shows about the way we work
Tailored to the real system
We did not start from an anonymisation template but from a diagnosis of the Service's specific process. The protocol was designed around the system as it is, not around an ideal one.
Methodological rigour
We applied formal privacy models and the European framework of the three re-identification attacks—singling out, linkage and inference—to the Service's real usage scenarios.
Tested, reproducible code
The prototype is delivered with 410 automated tests and reproducible runs under controlled conditions, while keeping the specific parameters of each instance and recipient.
Compatible with their infrastructure
The whole design is built to integrate with the pseudonymisation tool already in use and to adapt both to the current dimensional model and to the OMOP CDM schema being adopted, without redesigning the core logic.
Capabilities deployed in this project
Shall we talk?
Tell us what you are working on and we will give you a straight answer on how we can help.