🧬 What is Tokenization in Life Science?
Tokenization in Healthcare and Clinical Research refers to Privacy-Preserving method in which personally identifiable information (PII), such as name, date of birth, social security numbers, or other direct identifiers, is transformed into a consistent pseudonymous identifier (so called token). These tokens allow linkage of individual-level Data across different Datasets without revealing the underlying identity. In the context of secondary use of Clinical Data, tokenization enables the integration of trial Data with Electronic Health Records (EHRs), lab results, pharmacy records and other real-world Data (RWD). As emphasized by Walters et al. (2025), tokenization has become a central mechanism for creating longitudinal, linkable Datasets for secondary analyses particularly in the US context. Tokenization, however, results in pseudonymized rather than anonymized processing, because even if tokens are designed as a one-way (“irreversible”) hashed string, re-attribution remain possible if any party retains additional information enabling identification. Moreover, linked Datasets can become indirectly identifiable without appropriate risk management and governance controls (Walters et al., 2025).
⚙️ How does Tokenization work technically?
The technical process of tokenization involves usually several steps. First, Data is cleaned and normalized to ensure consistency. For example, variations such as “Bob”, “Rob”, “ROBERT” are standardized. Then, a tokenization engine uses one or more identifiers (typically name, birth date, gender, or ZIP code) to generate a token using a cryptographic function, often a hash or keyed transformation. The cryptographic function used in this context is a tool for pseudonym generation and supports consistent linkage, but it does not, by itself, guarantee anonymity of the resulting linked Dataset. The trusted third-party (‘TTP’) retains access to the original identifiers and the transformation logic behind. Tokens are typically designed as one-way (“irreversible”) outputs, but reidentification may remain possible under controlled conditions (linkage and auxiliary information). After the token generation, the TTP segregates identifiers within a controller environment (and may retain them under strict governance where it is justified) and only the tokenized Dataset is shared with the sponsor.
📚 Intuitive Analogy: the library and the invisible ink
Tokenization may be conceptualized using the analogy of a library containing thousands of books, each representing different sources of information or Data sets such as Clinical Trials, hospital Database, pharmacy Database, even insurers Database.
Some books contain Private diaries, recording the life of people involved in Clinical Trials. The challenge is to track one individual across several books or Database without revealing their name. Tokenization is like using ink to mark each appearance of a person, let’s say “Oksana Smith” with a unique symbol like “A93F1Z”. This symbol appears everywhere “Oksana” is mentioned, even in books by different authors, yet her identity remains not visible. You can follow her medical journey without knowing her name. This analogy captures the dual goal of tokenization: stable across Database and hiding identity. In practice, the “card catalog” containing direct identifiers must remain strictly separated and access-controlled (e.g., a secure portal or controlled environment), consistent with the operational model described by Walters et al. (2025)
📊 Why is Tokenization needed in Clinical Research?
The primary driver of tokenization in Clinical Research is the need to balance Data utility and Data Privacy. Regulatory frameworks such as GDPR (Recital 26 and Art. 4(5)) in Europe but also other Data Protection laws across the world impose strict restrictions on the use and sharing of PII (e.g. Lei Geral de Proteçao de Dados – LGPD; HIPAA Privacy Rule; Privacy Act 1988).
Tokenization can support compliant use and secondary use by minimizing the exposure of direct identifiers while enabling linkage for approved research purposes. However, it does not remove GDPR compliance obligations when the processing remains pseudonymized.
By tokenizing identities, researchers can merge Datasets from different sources to create longitudinal views of a patient’s health journey (Bernstam et al. 2022). For example, linking a person’s Clinical Trial participation with their long-term real-world outcomes in EHRs. Walters et al. (2025) highlight tokenization as an enabler of retrospective analyses that were not planned during the primary study design.
🧩 Types of Tokenization
Tokenization can be implemented through several architectural patterns. Walters et al. (2025) primarily describe trusted third-party mediated pseudonymisation: directly identifying information is processed by a specialized service that generates stable tokens. A second class corresponds to Privacy-preserving record linkage (PPRL) encodings where identifiers are transformed into deterministic or error-tolerant representations (e.g. Bloom-filter based methods) enabling linkage without sharing raw identifiers (Schnell et al., 2009). Finally, the third class refer to federated/distributed linkage. In this class, identifiers are not centralized: linkage is performed across organizations using federated algorithm (Heidt et al., 2021) or cryptographic protocols such as secure multi-party computation to reduce reliance on a single trusted intermediary (Stammler et al., 2022; Laud & Pankova, 2018)
🎯 Privacy Challenges and Limitations
Despite the utility, tokenization presents several privacy challenges.
Foremost, tokenization is not anonymization. Because the TTP retains access to the mapping between PII and tokens, the process is reversible under controlled conditions. This characteristic place fundamental limitation on the Privacy guarantees tokenization can offer. Walters et al. (2025) stress that tokenization must be complemented by Reidentification Risk Determination (RRD) and may require further transformations such as suppression, generalization, or date shifting to meet HIPAA deidentification standards.
Under the GDPR, tokenization typically remains legally classified as pseudonymized Personal Data regardless of the technical strength of the tokenization method. GDPR Recital 26 and Article 4(5) emphasize that pseudonymisation is a useful security measure, but this does not render Data anonymous, meaning all GDPR obligation remain fully applicable when using tokenization.
Beyond the legal classification, tokenization has inherent technical and operational limitations. Reidentification remains theoretically possible through several mechanisms. One of them comes from the use of low-entropy identifiers (e.g., names, date of birth, ZIP code) which can be susceptible to brute-force or dictionary attacks, extensively describe in the Privacy-preserving record linkage literature. More broadly, as Walters et al. observed, reidentification risk increases as more Data sets are linked. Each additional Data set enriches the attribute space associated with each token, making individuals more unique and therefore more identifiable through linkage attacks and statistical inference. This cumulative risk is a significant challenge, since the central value of tokenization lies precisely in enabling multi-Dataset linkage across Clinical Trial Data and EHRs.
Another limitation concerns the temporal instability. Token durability depends on the stability of the identifiers used to generate tokens. Over time, individuals may change names, addresses or other personal information, reducing the likelihood that newly generated tokens will match previously issued ones. Walters et al. refer to this as the “future-proofing problem” warning that tokens generated at baseline may lose accuracy as PII evolves. This can cause both false negatives (failing to link the same individual across time) and false positives (incorrectly linking records of different individuals) and introduce progressively methodological and ethical issues. These issues also have Privacy implications: failed linkage can create pressure to retain or reprocess original identifiers, while false linkage can expose individuals to misclassification or inappropriate Data aggregation.
A further challenge lies in the central role of TTP in the tokenization workflow. These models assume that the tokenization vendor will safeguard the PII to token mapping. However, this creates a single point of failure. Indeed, Privacy Protection is guaranteed not by cryptographic irreversibility but by organizational and contractual controls. Walters et al. (2025) emphasize that Privacy Protection relies on operation controls (secure handling of identifiers, separation of environments,…) and on reidentification risk and deidentification transformations applied to the linked Dataset. This means that Privacy depends on the integrity of the TTP rather than on purely mathematical guarantee.
This aspect introduces additional complexity in international context. In France, for example, the CNIL’s Methodologie de Référence (MR-001) restricts the transfer of directly identifiable Data to processors outside European Union in the context of Health Research requiring the consent of participants. A tokenization vendor based in the US might be blocked from receiving identifiers for token generation. This constraint forces projects to adopt federated tokenization architectures in which identifiers never leave the EU or to process tokenization in Europe.
Finally, tokenization faces algorithmic and transparency limitation. Usually, commercial companies use their own algorithms developed internally and researchers or regulators lack visibility into the token generation process to evaluate the robustness and susceptibility of reidentification attacks. FDA’s Real-World Evidence Framework and EMA’s guidance on Data linkage both emphasize the importance of transparency, reproducibility and auditability. Proprietary tokenization systems may not satisfy these expectations unless commercial companies provide detailed technical documentation and undergo independent review.
As a conclusion, these limitations show that while tokenization enables powerful Database linkage and potential secondary uses of Clinical Trial Data, it must be implemented within a comprehensive Privacy governance framework. This includes regulatory review, risk assessment, contractual safeguards, and technical measures. Tokenization should therefore be understood not as a guarantee of anonymity but as one layer within a broader system of Data Protection which interact with different Privacy regulation and must be evaluated accordingly.
Bernstam EV, Applegate RJ, Yu A, Chaudhari D, Liu T, Coda A, Leshin J. Real-World Matching Performance of Deidentified Record-Linking Tokens. Appl Clin Inform. 2022 Aug;13(4):865-873. doi: 10.1055/a-1910-4154. Epub 2022 Jul 27. PMID: 35896508; PMCID: PMC9474266.
Heidt CM, Hund H, Fegeler C. A Federated Record Linkage Algorithm for Secure Medical Data Sharing. Stud Health Technol Inform. 2021 May 24;278:142-149. doi: 10.3233/SHTI210062. PMID: 34042887.
Laud P, Pankova A. Privacy-preserving record linkage in large databases using secure multiparty computation. BMC Med Genomics. 2018 Oct 11;11(Suppl 4):84. doi: 10.1186/s12920-018-0400-8. PMID: 30309353; PMCID: PMC6180364.
Schnell R, Bachteler T, Reiher J. Privacy-preserving record linkage using Bloom filters. BMC Med Inform Decis Mak. 2009 Aug 25;9:41. doi: 10.1186/1472-6947-9-41. PMID: 19706187; PMCID: PMC2753305.
Stammler S, Kussel T, Schoppmann P, Stampe F, Tremper G, Katzenbeisser S, Hamacher K, Lablans M. Mainzelliste SecureEpiLinker (MainSEL): privacy-preserving record linkage using secure multi-party computation. Bioinformatics. 2022 Mar 4;38(6):1657-1668. doi: 10.1093/bioinformatics/btaa764. PMID: 32871006; PMCID: PMC8896632.
Walters C, Langlais CS, Oakkar EE, Hoogendoorn WE, Coutcher JB and Van Zandt M (2025) Implementing tokenization in clinical research to expand real-world insights. Front. Drug Saf. Regul. 5:1519307. doi: 10.3389/fdsfr.2025.1519307
Author: Gregory Collet
