IRB Re-Contact Protocol: Reversible Encryption Guide
IRBs now ask for more than a de-ID plan. They also need a re-contact plan. You must show two things. First, outside parties cannot reach real patient names. Second, your team can — when ethics approval says so.
This two-part rule comes from real experience. Long studies have found urgent results mid-trial. But the records were locked. No path back existed. That blocked patient care. Regulators took note.
See how we support this in our compliance overview and security practices.
Why IRBs Need a Two-Way Door
GDPR fines rose 56% in 2024 (DLA Piper Annual Report 2025). GDPR Article 89 responds to that trend. It requires pseudonymization — not full removal — for research data. The rule accepts that research sometimes needs a path back to the real record.
A 2024 NEJM AI paper studied LLM-based de-ID. It found a core problem. Scrubbed clinical notes stay tied to patient identity through the same clinical patterns that make them useful. The paper says: use pseudonymization with a documented key plan. That keeps the re-contact path open.
Your IRB needs to see both sides of that door. Who can re-identify? Under what terms? Who holds the key? What gets logged?
How the Setup Works
AES-256-GCM runs in a fixed mode. Each patient ID always maps to the same token. "Patient_001" gives the same output each time. That token shows up at baseline, at 3 months, and at final review. The team tracks each patient using the token alone. No real names enter the work files.
Key split meets the EDPB rule. The research team holds the encrypted data. A data custodian holds the key in a separate system. Neither side can re-identify alone. The team cannot decrypt. The custodian cannot link keys to patients without the data.
When re-contact is approved, the custodian applies the key to named records. Each step is logged: which records, when, who gave the approval. That log is your GDPR Article 89 proof.
What This Looks Like in Practice
An oncology center runs a 5,000-patient cohort in three countries. Each site works with tokens only. The lead center's data officer holds the key.
Mid-study, a scan flags 47 patients with high risk. The ethics board approves re-contact. The officer decrypts those 47 records. The care team reaches those 47 patients. The other 4,953 stay hidden at all three sites.
The key does not move. The data stays encrypted. Only those 47 records are ever linked to real names.
For more on pseudonymization vs. full anonymization, see our reversible de-identification guide.
When This Approach Has Limits
A deterministic token plus a split-custody key is the right way to satisfy an IRB that wants both protection and a documented path back. But limits remain worth stating plainly.
A documented key plan keeps the data identifiable by design. The NEJM finding is the deeper point here: even with names tokenized, clinical notes stay tied to a patient through the same patterns that make them useful, and the held key makes re-identification deliberate. This is pseudonymized research data under Article 89, not anonymized data. It stays in full regulatory scope, so the lighter obligations that attach to truly anonymous datasets do not apply, and the dataset cannot be freely shared as if de-identified.
Split custody controls the key, not the residual signal. Holding encrypted data and key in separate systems is a strong control, but it bounds who can re-link, not whether the records could be re-linked by other means. Rare diagnoses, small-cohort sites, dates of service, and geography can single out a patient even with the token in place. In a 5,000-patient multi-country cohort, a distinctive case at one site may be identifiable from quasi-identifiers alone. Custody discipline does not remove that residual risk.
The decision to re-contact is an ethics judgment, not a decryption step. The custodian can apply the key in minutes, but whether a mid-study finding justifies re-contact, how to approach a patient safely, and what the consent permitted are determinations for the ethics board and the care team. The audit log proves the key was used under approval; it does not make the underlying clinical and ethical call. The tool enables the protocol; people still have to run it.