Why this matters
Participant privacy is both an ethical duty and a legal requirement. Good clinical data management collects only what is needed, keeps any “cross‑walk” that links real‑world identities to study IDs separate and secured, and makes access traceable. The challenge is to do this without harming analysis (e.g., timelines, safety signals, or endpoints). The tools: minimal collection, pseudonymization (replace identifiers with tokens while keeping a secure key), and consistent de‑identification (predictable, documented transforms). Privacy laws (e.g., the EU General Data Protection Regulation (GDPR) or US HIPAA), ICH E6 and the informed consent set the rules: records that could identify participants stay confidential.
Bottom line: A dataset used for analysis carries no direct identifiers, and once it leaves the study team it should be useful for science and worthless for re‑identifying people.
Identifiers: what, why, where
Direct identifiers (high risk — avoid in analysis)
These immediately identify a person:
- Full name, medical record number (MRN), Social Security number (SSN) or other national ID number, email, phone, full street address, photos of the face, exact GPS coordinates.
- Where they belong: at the site (medical records and the investigator’s confidential subject identification code list, linking each participant to their subject ID) and in operational systems that need them for a task the consent covers (e.g., shipping devices home). The sponsor’s Electronic Data Capture (EDC) system holds subject IDs, not names or contact details.
- Where they do not belong: analysis extracts, data lakes used by study statisticians, dashboards shared beyond the minimum necessary.
Quasi‑identifiers (indirect — handle with care)
These can identify a person when combined:
- Date of birth, exact dates of visit/procedure, detailed geography (ZIP/postcode), race/ethnicity, rare diagnoses or procedures, free‑text notes.
- Typical approach: keep precise values only where needed (e.g., real visit dates in the access‑controlled study database); transform them in extracts shared beyond the study team (e.g., age bands, relative days). Collect age or year of birth, not a full date of birth, when the protocol allows.
Operational vs analysis use
- Operational: scheduling, shipping devices/diaries, reminding participants, issue resolution. Needs some direct identifiers but strictly limited to those staff and systems.
- Analysis: data cleaning, listing generation, statistical modeling, safety review. No direct identifiers needed: the study team works with subject IDs; data shared beyond it also get transformed quasi‑identifiers.
Tip: Watch for “hidden” identifiers in file metadata (PDF author, DICOM (medical imaging file) headers), logs, and free text (“Patient Mary called…”). Treat them like identifiers.
Subject IDs & key management
ID strategy
- Assign site‑unique → study‑unique subject IDs. A simple, readable format helps: e.g.,
SITE-####/SUBJ-####. Never build an ID from personal data (initials, date of birth, MRN); that is not a pseudonym. - Never reuse a subject ID, even if a participant screen‑fails and later reconsents. Use a new ID and record the relationship operationally.
Pseudonymization (linkable, not identifiable)
Replace real‑world identifiers with a token (subject ID).
Keep the linkage register (the “cross‑walk” between token and identity) in a separate, access‑controlled key store. For subject IDs, that is the site’s subject identification code list; the sponsor sees only coded data.
Use a deterministic method for cross‑study linkage when required (e.g., a tokenization service or a keyed hash such as HMAC; without the secret key, guessed names and birth dates cannot be hashed into matching tokens).
- Salt/secret is stored outside code and data, kept separate per program/purpose (tokens made with different secrets do not link), and access‑logged.
Who can access the key store? The smallest possible group (for the site’s subject identification code list, named site staff; for a sponsor‑side token key, a designated custodian outside the sponsor’s study team, e.g., the tokenization vendor) with written approval and audit trails. Unlike the randomization (unblinding) code, it reveals identity, not treatment.
Practical controls
- Store keys in a system different from where analysis data lives.
- Enforce dual control for key export (two people approve).
- Maintain break‑glass procedures (urgent access outside normal approval) for emergencies with automatic notifications and post‑access review.
De‑identification patterns
Dates
Policy: the study database and submission datasets (e.g., CDISC SDTM) keep real dates; in extracts shared beyond the study team (e.g., data‑sharing requests), use one of:
- Relative study days: count days from a reference event (e.g., randomization/first dose). In CDISC SDTM the reference date is Day 1 and the day before is Day −1 (no Day 0): 7 days after randomization is Day 8, 14 days before is Day −14. State the convention in the specification.
- Subject‑level date shift: add/subtract a fixed, random shift per subject (e.g., between ‑180 and +180 days). Keep the shift value only in the secure key store, not with the dataset.
Be consistent within a subject and document the chosen method so repeated extracts match. Both methods keep intervals within a subject but lose calendar time (e.g., season), so agree with biostatistics which analyses need real dates.
Small‑cell rules (suppress rare counts)
- If a table cell has fewer than an approved threshold (commonly 5 or 11), suppress or aggregate categories (“Other/Combined”). If totals are shown, also suppress or combine a second cell, or the hidden count can be found by subtraction.
- Apply the same rule to combinations of variables (e.g., age × site × event). Document your threshold in the data‑sharing plan.
Rare demographics & geography
- Age: use bands (e.g., 18–25, 26–35…; often top‑code as 90+).
- Geography: use broader regions (e.g., 3‑digit postcode or region rather than full code), and replace very small geographies with “Unknown/Region”.
Free text & documents
- Avoid collecting free text. If needed, scan and redact personal names, contact details, workplaces, and locations.
- For images and device files (e.g., DICOM), remove or replace the identifying header fields (keep the technical ones the analysis needs) and inspect for burned‑in text.
Traceability & reversibility
- Maintain a De‑identification Specification: exactly what transforms are applied, by which code version, and when.
- If an Institutional Review Board (IRB) or ethics board allows re‑linking, keep the minimal private lookup needed to reverse transforms. Access must be approved and logged.
Access integrity & audit trails
Least privilege by design
- Role‑based access: grant only what a person needs for their job, and only after role training.
- Time‑boxed access for temporary roles (e.g., interim analyses).
Technical controls (beyond training)
- Personal (named) accounts only, never shared or generic, so every action and e‑signature traces to one person.
- Single active session per user and multi‑factor authentication (MFA).
- Device trust (company‑managed devices) and, where appropriate, IP allow‑lists or geo‑blocking.
- Download controls: watermarking, read‑only views, and flagged exports.
Monitoring & auditability
- Log who/what/when/why for access to identifiers, key stores, and exports.
- Quarterly access reviews; remove access within 24–48 hours when someone changes roles or leaves.
- Keep audit trails for at least as long as the data they govern.
Pitfalls & misconceptions
“Just in case” hoarding: Keeping MRN/SSN or exact date of birth in analysis datasets “for later” is unnecessary and risky.
Shifting dates inconsistently: Changing the date‑shift method mid‑study breaks reproducibility and can hide safety signals.
Free‑text leaks: Comments like “Spoke to John Smith at 555‑… about dosing” defeat de‑identification.
Mixing keys and data: Storing the pseudonymization salt or linkage file with the dataset is equivalent to not de‑identifying.
Assuming training stops credential sharing: Add technical measures (single session, MFA, monitoring).
Confusing terms:
- Pseudonymized = re‑linkable with a key (common in clinical research); still personal data under the GDPR, so the same protections apply.
- Anonymized = not re‑linkable (rare in regulated research where traceability is needed).
Practice checklist
- Separate operational identifiers from analysis extracts.
- Issue study‑unique subject IDs; no reuse.
- Implement pseudonymization via a segregated key store; log all access.
- Define, document, and automate date handling (relative days or subject shifts).
- Apply small‑cell rules and category coarsening consistently.
- Scan and redact free text and file metadata.
- Enforce single session + MFA; review access quarterly; de‑provision within 24–48h.
Worked examples
1) Subject ID and cross‑study linkage — done safely
Scenario: A participant enrolls in two studies run by the same sponsor. You need to detect duplicate participation without storing names in analysis datasets.
Approach:
- At screening, the site records identity information in its own operational records (not in the sponsor’s EDC); the consent covers the duplicate check.
- The site’s tokenization software turns a stable set of fields (e.g., legal name, date of birth, sex) into a linking token; the identifying fields never leave the site.
- The token is stored in a key store mapped to the subject’s study ID; analysis datasets include only the study ID.
- To check cross‑study duplicates, authorized staff query the token (not the identity).
Why this works: Analysts never see direct identifiers; linkage is possible only through a controlled service and audited key store.
2) Dates in shared extracts — relative days
Scenario: An approved data‑sharing request needs event timelines, but real dates may not leave the study database.
Approach:
- Define Day 1 as the randomization date (or first dose), as CDISC SDTM study days do.
- Convert every other date to Day +N / Day −N relative to it (the day before Day 1 is Day −1; there is no Day 0).
- Real dates stay in the study database and submission datasets; the shared extract carries only study days.
Result: The requester sees the sequence and spacing of events (e.g., “AE on Day +12; SAE on Day +13”), which is usually all they need.
3) Small‑cell suppression in a demographics table
Scenario: A country‑level race/ethnicity table shows 3 participants in a rare category. Your rule suppresses counts below 5.
Approach:
- Combine rare categories into “Other/Combined” until that cell holds at least 5 (here, the 3 plus at least 2 more), and footnote the suppression rule in the table spec.
Result: Counts below the threshold are not displayed, reducing re‑identification risk while preserving totals.
4) Cleaning free‑text fields before export
Scenario: A concomitant medication comment reads: “Patient Mary Adams called from (206) 555‑0132—rescheduled dose.”
Approach:
- Run a redaction pass on the extract to remove names, phone numbers, emails, and locations.
- Query the site to remove the identifiers from the EDC comment; the site corrects it (DM never edits site data).
- The original stays in the EDC audit trail, which never hides an original entry, so remind the site to keep names and contact details out of EDC fields.
Result (analysis): “Patient [redacted] called — rescheduled dose.”
5) Imaging data with hidden identifiers
Scenario: You receive DICOM files from a site. Names are removed from the form, but images still contain burned‑in text.
Approach:
- Replace identifying DICOM header fields (e.g., patient name, ID, birth date) with the subject ID or blanks, keep the technical fields, and scan images for text overlays; mask any detected text before sharing for analysis.
Result: Analysts receive images free of both header and visible identifiers.
Key points to remember
- Collect the minimum necessary identifiers and keep direct identifiers out of analysis; separate operational stores from analysis extracts.
- Subject IDs & pseudonymization: issue site/study‑unique IDs (no reuse); keep the identity ↔ ID linkage at the site (subject identification code list) and any linkage token or secret key in a segregated, access‑logged key store with dual control. Never store salts/secrets or linkage files with the dataset; use deterministic tokens only when cross‑study linkage is required.
- Pseudonymized ≠ anonymized: re‑linking is permitted only via an approved, audited process; full anonymization is uncommon where traceability is required.
- Dates in shared extracts: choose relative study days or a fixed subject‑level shift and apply it consistently; real dates stay in the study database and submission datasets; avoid mid‑study method changes.
- Quasi‑identifiers in shared extracts: coarsen values (e.g., age bands, regional geography) and apply small‑cell suppression below your threshold—including for combinations (e.g., age × site).
- Free text & file metadata: minimize collection; scan/redact names, contacts, and locations; strip identifying header fields and metadata from files (e.g., DICOM/PDF) and mask any burned‑in text.
- Access integrity: enforce personal accounts, least privilege, time‑boxed roles, MFA, and single active session; consider device trust/IP allow‑lists; use watermarking/read‑only exports when appropriate.
- Monitoring & auditability: log who/what/when/why for identifiers, key stores, and exports; run quarterly access reviews and de‑provision within 24–48h; retain audit trails as long as the governed data.
- Documentation & reproducibility: maintain a De‑identification Specification, code/version history, and linkage governance so repeated extracts match.
- Avoid common pitfalls: “just‑in‑case” hoarding of identifiers, mixing keys with data, inconsistent date shifting, and relying on training alone to deter credential sharing.