Health data anonymisation

No. Removing direct identifiers, such as names or national ID numbers, does not anonymise the data, because re-identification comes mainly from combining quasi-identifiers. This applies to any health data extract you want to release or share, where apparently harmless variables, such as age, postcode, an admission date or a rare diagnosis, are enough in combination to single out a person. The anonymisation framework starts from the three re-identification attacks (singling out, linkage and inference) and prescribes, for each type of request, which variables have to be treated and to what threshold. Removing the direct identifier is only the first step. The combination of quasi-identifiers is the real vector, and it is the one a formal framework bounds measurably. Anonymisation is a matter of combinations, not of deleting a column.

k-anonymity is a formal property that requires every combination of quasi-identifiers to appear in at least k individuals, so that no one is unique on that combination. It applies to the treatment of health microdata, where the risk of singling out is high. On that basis, l-diversity adds a condition on the sensitive variables: within each group there must be enough variety that belonging to the group does not reveal the sensitive attribute. The specific values of k and l are not universal. They correspond to each class of request according to its use and granularity, and are set in the decision tree. One limit is worth stating: these models bound the risk measurably, they do not eliminate it, and the protection they offer depends on which variables are treated as quasi-identifiers. What they provide is a formal, verifiable bound on the risk accepted, not a promise that re-identification is absolutely impossible.

Not necessarily: the framework aims to bound re-identification risk while preserving analytical utility, choosing the technique by output type instead of applying one technique to everything. This applies when you are concerned that anonymisation will leave the data unusable for the planned analysis. For microdata, the options are hierarchical generalisation, suppression, microaggregation or date shifting, with the appropriate k-anonymity and l-diversity thresholds. For publishable aggregates, differential privacy limits what a third party could infer, and the table stays useful when the noise level is compatible with the intended use. The key is that the model is chosen by output type and intended use, not imposed as a single model that ruins everything else. There is a real trade-off between privacy and utility, and the framework manages it explicitly and with documentation, not blindly. The aim is the treatment that protects people without destroying the research question.

That cross-referencing is a real risk, and per-instance pseudonymisation reduces it: a different pseudonym in each extract prevents the outputs for the same individual from being linked across deliveries. This applies to any organisation that releases data recurrently from the same registry or system. A pseudonym that is stable across deliveries, the same code for the same person in every extract, would make it possible to reconstruct that person's full trajectory by cross-referencing outputs, even if each one looked safe on its own. Generating a different pseudonym for each instance breaks the direct identifier link between deliveries. It is implemented reproducibly through HMAC-based derivation, so that the process is consistent and can be re-run. The limit: this protects against linkage across extracts, and it does not replace the treatment of quasi-identifiers within each one. It is the piece that stops repeated releases from undoing the anonymisation of each delivery.

No. The health data anonymisation service does not offer assurance of GDPR compliance or a legal validation of the anonymisation, because that is a legal assessment that belongs to another field. What we design is the methodological framework: the classification of requests, the formal privacy models, the verifiable thresholds and the pre-delivery checklist that put formal bounds on re-identification risk. This limit is worth stating because "anonymisation" has a legal reading as well as a technical one, and the two should not be confused. How robust the result is in practice also depends on how the client implements and maintains the process in its own environment: ADI designs the protocol and analyses the risk; the organisation owns the data, releases them and operates the framework. What you receive is a traceable, verifiable methodological assessment of the risk accepted, not an opinion on regulatory compliance.

No. Absolute irreversibility cannot be promised, because no serious anonymisation framework can claim that re-identification will be impossible under every future circumstance. This applies to any release of health data, where risk is managed and bounded, not eliminated altogether. What the framework does is quantify and limit that risk measurably: k-anonymity and l-diversity thresholds bound singling out and linkage, differential privacy limits inference from aggregates, and the checklist blocks anything that falls short of the threshold before delivery. The residual risk also depends on the auxiliary data a third party may hold and on what information becomes available in the future. That is why we speak of formal bounds on the risk accepted, with their assumptions stated, not of re-identification being impossible. Anonymising well means bounding the risk at a known, justified level, not promising the impossible.

Health data anonymisation is used when the aim is to release or share data while reducing the risk that people are re-identified, by treating quasi-identifiers and sensitive variables. Data traceability and forensic watermarking fit when what you need is to identify the source of a leak or to show where an extract came from, by marking the data so that every copy can be attributed. They are sequential and complementary, since an organisation can anonymise data to release them and also watermark each delivery to trace its source. But they do not answer the same question: anonymisation protects people against re-identification; forensic watermarking protects the organisation against unauthorised dissemination. They can be commissioned separately or as a linked process, depending on what you need.

The health data anonymisation service delivers the methodological framework: the classification of requests by use and granularity, the decision trees that prescribe techniques and thresholds for each class, the formal privacy models applied by output type and the pre-delivery validation checklist. ADI designs the protocol, defines the thresholds and analyses the risk; the organisation owns the data, releases them and operates the framework day to day. The protocol is designed to be reproducible and verifiable. The categories, trees and checklist are documented, so the treatment applied to each delivery can be reviewed, maintained and re-run without ambiguity. What you receive is not a one-off anonymised extract, but a reproducible framework for applying consistent treatment to the same class of request.