What Is Privacy-Preserving Record Linkage (PPRL)?

Privacy-preserving record linkage (PPRL) is a set of techniques for determining which records in two or more separately held datasets refer to the same person — without any party revealing the identifying details of its records to the others. Instead of exchanging names, dates of birth, or medical record numbers, each data holder encodes its identifiers into irreversible tokens or cryptographic structures such as Bloom filters, and the matching is performed on the encoded values. PPRL is what makes it possible to ask “how many patients appear in both hospital A and registry B?” while the underlying identifiers never leave their custodians.

Why PPRL matters now

Health research increasingly depends on joining datasets that no single organisation holds: hospital records with disease registries, genomic cohorts with prescribing data, trial candidates with real-world outcomes. Classic record linkage solved this by shipping identifiers to a central matching service — a model that modern law and modern risk tolerance have made progressively harder to defend. Under the General Data Protection Regulation (GDPR), pseudonymised identifiers remain personal data, so centralising them is a regulated processing and transfer event; the European Health Data Space (EHDS) regulation pushes secondary use into secure processing environments; and the May 2026 UK Biobank incident — in which approved researchers exported participant-level data through a centralised platform’s routine workflow — hardened custodians against any design that concentrates identifiable data in one place. PPRL answers the same scientific need with the opposite architecture: the linkage question travels to the data, and the data never leaves the source. That inversion is why PPRL has become a core primitive of federation in health research.

How privacy-preserving record linkage works

From identifiers to irreversible encodings

PPRL begins with standardisation: each site normalises its identifiers — trimming whitespace, casing names consistently, formatting dates — because encoded matching amplifies formatting noise. Each site then transforms its identifiers using a shared, secret-keyed scheme. The simplest approach is keyed hashing: applying a cryptographic hash-based message authentication code (HMAC) to a concatenation of fields, producing a token that is stable for identical inputs but computationally infeasible to reverse. Exact-hash tokens, however, are brittle — “Katherine” and “Catherine” hash to unrelated values — which is why the field’s dominant technique is the Bloom-filter encoding introduced by Schnell, Bachteler, and Reiher in BMC Medical Informatics and Decision Making (2009). Each identifier is split into overlapping two-character fragments (bigrams), and each bigram is hashed into positions of a fixed-length bit array. Similar names share bigrams, so their Bloom filters share set bits, and the similarity of two encodings — typically measured with a Dice coefficient — approximates the similarity of the underlying strings without exposing them.

Matching, scoring, and the honest broker

Matching then follows the probabilistic framework formalised by Fellegi and Sunter in 1969: candidate pairs are scored on the agreement of their encoded fields, weights reflect how discriminating each field is, and thresholds separate matches, non-matches, and pairs for review. In PPRL the comparison runs over encodings rather than clear text, and it is usually orchestrated by an honest broker — a party (or a piece of neutral infrastructure) that receives only the encoded tokens from each site, computes the match, and returns linkage results, holding neither the identifiers nor the clinical payload. The separation is deliberate and structural: the sites hold identifiers but never see each other’s; the broker sees encodings but no identifiers or health data; researchers see linked analytical results but neither. No single party in the workflow can reconstruct the full picture, which is precisely the property regulators and custodians require.

Security considerations

PPRL is not magic dust, and honest evaluation matters. Naive Bloom-filter encodings have known weaknesses: published cryptanalyses have shown that frequency analysis over large populations can partially recover common names from unhardened filters. Production deployments therefore apply hardening — record-level salting, keyed hashing with secrets shared only among data holders, balanced or permuted filters, and strict separation between whoever holds the key and whoever performs matching — alongside conventional controls such as rate limiting and audit logging. The design assumption should be that encodings are sensitive artefacts deserving protection in their own right, not public-safe ciphertext. Where threat models justify it, more computationally expensive alternatives exist — secure multi-party computation and homomorphic-encryption protocols can compute matches with formally provable privacy — but Bloom-filter PPRL remains the practical default because it scales to millions of records at linkage quality close to clear-text methods.

PPRL vs traditional record linkage

The federation angle: linkage without a data pool

PPRL is most powerful as a component of a larger federated architecture rather than a standalone tool. In a federated Trusted Research Environment (TRE), each custodian keeps its clinical and genomic data inside its own boundary; approved analyses are dispatched to each site and only aggregate, disclosure-checked results return. PPRL slots into this topology as the identity layer of federation: encoded tokens let the network answer cross-site questions — cohort overlap between institutions, deduplication of patients counted twice, longitudinal trajectories spanning providers — while the identifying data and the health data both stay put. The pattern pairs naturally with federated analytics, where statistics are computed at each site and combined centrally; the distinction between that and model training across sites is covered in federated analytics vs federated learning. Without PPRL, federation can compute within sites but cannot reason about identity across them; with it, a federated network gains the analytical reach of a pooled dataset while preserving the sovereignty guarantees that persuaded custodians to join in the first place.

Real-world use: where PPRL earns its keep

The technique is now standard machinery in national and multi-site research. National statistics institutes — including the UK Office for National Statistics, whose Five Safes framework governs most TRE access — have long research programmes in privacy-preserving linkage methodology for joining administrative and health datasets. Disease registries use PPRL to deduplicate case reports arriving from many hospitals. Clinical trial sponsors use tokenised linkage to connect trial participants to real-world data for long-term follow-up without holding their identities. And federated research networks use it for cross-site overlap assessment: when two academic medical centres both claim tens of thousands of eligible patients, PPRL reveals how many are the same people — a question Lifebit’s federated platform answers with Bloom-filter tokenisation executed inside each custodian’s environment, so that even the encodings are generated behind the custodian’s firewall and the overlap is computed without any identifier crossing it.

Common pitfalls

Four mistakes account for most failed or risky PPRL deployments. Skipping standardisation: encoding amplifies formatting inconsistency, so sites that hash unstandardised fields see match rates collapse and conclude the method does not work. Treating tokens as anonymous: keyed encodings of personal identifiers are generally still pseudonymised personal data under GDPR — they minimise exposure, they do not exit the regulation, and they must be governed accordingly. Weak key ceremony: if the party performing matching also holds the encoding key, the privacy model quietly collapses into trust in one organisation; keys must stay with data holders, separated from the broker. Ignoring linkage error in analysis: every linkage method produces false matches and misses, and PPRL’s error profile differs from clear-text linkage — downstream studies should quantify and report linkage quality rather than assume it, as recommended in reporting guidance for linked-data studies such as the GUILD and RECORD frameworks.

What to do next

Teams evaluating PPRL should start with a small, measurable pilot: choose two datasets with a known or estimable overlap, standardise identifier fields against a shared specification, and compare Bloom-filter linkage quality against a clear-text baseline on a consented or synthetic subset before trusting it in production. Decide the trust topology explicitly — who holds keys, who computes matches, who sees results — and write it down as a data flow that a regulator could audit. Then decide where PPRL sits architecturally: as a one-off linkage project, or as the identity layer of a persistent federated network in which Trusted Research Environments at each site handle analysis and PPRL handles cross-site identity. The second option costs more thought up front and repays it every time a new collaboration starts — because the federation, and the linkage capability inside it, is already built.

Frequently asked questions

What is privacy-preserving record linkage (PPRL)?

PPRL is a family of techniques for identifying which records in separately held datasets belong to the same person without any party disclosing identifiers to the others. Sites encode names, dates of birth, and similar fields into irreversible tokens or Bloom filters, and matching is performed on the encodings.

How do Bloom filters work in PPRL?

Each identifier is broken into overlapping two-character fragments, and each fragment is hashed into positions of a fixed-length bit array. Similar strings share fragments and therefore share set bits, so comparing two Bloom filters with a similarity coefficient approximates how alike the original values are — tolerating typos and spelling variants without revealing the values themselves.

Is PPRL exact or probabilistic matching?

Usually probabilistic. Most deployments score candidate pairs across several encoded fields using the Fellegi–Sunter framework, weighting each field by how discriminating it is and applying thresholds for match, non-match, and review. Exact-token deterministic matching is also used where identifiers are highly reliable.

Are PPRL tokens anonymous under GDPR?

Generally no. Keyed encodings of personal identifiers are typically pseudonymised personal data, because re-linkage is possible with the key and additional information. PPRL reduces exposure and avoids pooling identifiers, but the encodings still require governance, security, and a lawful basis.

What is an honest broker in record linkage?

An honest broker is a neutral party or system that receives only encoded tokens from each data holder, performs the matching, and returns linkage results. It never holds clear-text identifiers or clinical data, so no single participant in the workflow can assemble both identity and health information.

How accurate is PPRL compared with clear-text linkage?

With well-standardised input fields and tuned Bloom-filter parameters, PPRL linkage quality approaches that of clear-text probabilistic linkage in published evaluations. Accuracy degrades when sites skip standardisation or rely on exact hash tokens, which cannot tolerate typographical variation.

How does PPRL fit into a federated TRE?

PPRL acts as the identity layer of a federated network: each custodian generates encodings inside its own environment, cross-site overlap and deduplication are computed on those encodings, and all clinical analysis continues to run where the data lives. The network gains pooled-data reach while every dataset stays under its custodian’s control.