Anonymisation decisions in one published package
The Policy 0070 package published for Voydeya, an orphan medicine, shows anonymisation decided one identifier and one study at a time. Personal data were retained by default and recoded, generalised or redacted only where a value could single out a participant, and the pivotal report was written so that its body needed almost no redaction.
The product, the documents and the risk
Voydeya is an oral small-molecule new chemical entity with orphan drug designation, and its package came from an initial marketing authorisation application. The marketing authorisation holder is the European entity of AstraZeneca's rare disease unit, and the package is on the agency's clinical data website, where a search for the product or its active substance shows the holder and the procedure number.
The package held 160 documents in scope: the clinical overview, the clinical summaries, and in module 5 all the clinical study reports with their selected appendices, together with an integrated summary of safety that had been submitted to the FDA. Because Voydeya is an oral drug and a new entity, it has many clinical studies, phase 1 studies especially, as is typical for an oral drug. Voydeya had 25 clinical studies, all very small, with sample sizes from 8 to 84.
The indication, paroxysmal nocturnal haemoglobinuria, is a rare disease, so the studies had few participants, and those few were scattered across many sites and countries, sometimes one at a site. So the risk of re-identification was high.
The objective, the team and the sequence of work
The team anonymised personal data only and anonymised no commercially confidential information, and none was identified in the package. Its goal was a balance between protecting the data and preserving their utility.
The work was cross-functional. Medical writers and clinical researchers worked with technical staff, document specialists and legal experts, and with clinical trial transparency, regulatory affairs and biostatistics, while the legal team went through the whole package for data protection. The team used anonymisation software and a vendor.
The work ran in a fixed sequence: the documents in scope were identified, put through a risk assessment and given a methodology decision, and then anonymised, with the anonymisation report prepared in parallel. The risk assessment began by identifying the data variables in the reports, the direct and the indirect identifiers. The methodology was chosen study by study, and both quantitative and qualitative assessment were used. One phase 2 study had only 10 patients, for example, so it was assessed qualitatively.
Direct identifiers
The default was to retain as much information as possible. The names of principal or coordinating investigators and the names of the sponsor in the clinical study reports were retained, and so were corporate addresses and contact details. Participant identification numbers were not redacted but, in most cases, recoded or transformed.
Names and signatures were redacted, with the principal investigator's name the exception. Signatures were redacted by default, whether wet ink or electronic. So were the contact details of site personnel who were neither the investigator nor the sponsor.
IP addresses were missed. The agency came back to say that they had to be redacted too, and the software, which flags what needs redaction, had not picked them up, probably because the requirement was relatively new.
Indirect identifiers
Each indirect identifier was decided per study. Sex and gender were redacted by default but retained in a phase 1 study in which all participants were male, where redacting them made no sense, and in the 84-patient phase 3 study, which had no outliers. Age was generalised into age bands by default and never redacted, except in studies with outliers, such as participants of an advanced age. Race and ethnicity were redacted by default but retained in a study of a single race in a Japanese population, where there was no reason to redact. In another study the majority race, white, was kept and the minority groups were pooled and recoded as other, which kept as much of the information as possible. Dates were retained as far as possible but transformed into study day rather than calendar date.
All of these decisions rest on the principle of singling out: the data that have to be redacted or anonymised are those unique enough to single out an individual. So redaction was not done indiscriminately, as it sometimes is for rare diseases.
Clinical variables
Adverse events and medical history were retained by default and redacted only where they were sensitive. Concomitant medications were retained too, and redacted where they were sensitive or inferential.
Sensitive information means adverse events, medical history and concomitant medications that are unique or rare in the population, and it was redacted across the whole package. Examples are a rare disease diagnosis other than the indication of the drug, a condition that is newsworthy or carries a negative association, and anything that could harm the participant's privacy.
A concomitant medication is inferential when it gives away what has been redacted elsewhere. An oral contraceptive gives away a participant's sex even when the sex itself is redacted, and a brand name specific to certain countries or regions gives away geographic location.
The software flagged every potentially sensitive item, and there were many. The team then decided whether to redact or retain each one. In one narrative, for example, the software flagged an item of medical history, a medical reviewer agreed that it was sensitive, and it was redacted.
Of the up to five variables of highest data utility that could be listed, the team listed four: gender, age, adverse events and medical history. So these were mainly retained, banded or generalised.
Techniques and the two routes to them
The package applied generalisation and banding, recoding, transformation and offsetting. Redaction, or blackening out, is very common and the easy way out, and the team did not take that way out.
Both routes to anonymisation were used. Proactive anonymisation protects the data while the reports are being written, with disclosure in mind. Reactive anonymisation leaves the reports as written and anonymises them afterwards.
The pivotal report written for disclosure
The phase 3 clinical study report was written with disclosure and data protection in mind, with a great deal of proactive anonymisation from the start. It held no commercially confidential information and no participant identification number in its body. The body, Sections 1 to 12 in the ICH E3 numbering, discussed safety by narrative number instead and cross-linked to the narratives in a separate document.
Biostatistics was asked from the start to give study day alongside the calendar date in the listings. So a writer describing an event could write study day 43 rather than a date, and the date matters only in relation to the study. Full calendar dates in the report and the listings were generalised to the year, which minimises the risk of re-identification. Demographics were used minimally in the body. They appeared, together with direct and indirect identifiers, only in the narratives, in section 14.3.3.
The writer who led the submission insisted that the phase 3 report be written this way because the package would be something of a showcase of the relaunched policy, one of the very first.
Writing could not cover everything, so anonymisation continued while the redaction package was prepared. The software recoded the participant identification numbers at random, by algorithm, and ages were banded. In the narrative shown as an example, gender was retained and race was redacted, because the participant was probably of a minority and so could be an outlier.
What the proactive writing saved
The body of the phase 3 report needed very little redaction. As the lead writer recalls, only the signature was redacted, and most of the redaction fell in the narratives. Across the package, redaction was limited to information that was unique, sensitive or inferential, and the clinical modules took a similar approach. Because the software did not do the work alone, and the medical writing had already contributed a great deal, the package needed only minimal redaction.
The earlier phase 1 and phase 2 documents in the same package were written without that care, and they carry a great deal of redaction.
The team judged that it reached its goal: a package that protected participants' data and preserved their utility, which matters to the scientific and medical community and to patients, especially in rare disease.
From preparation to publication
The marketing authorisation application was submitted in 2023 and reached procedure day 20 in July 2023. The following month the agency's invitation letter said that the package was eligible for the relaunch of Policy 0070. A month later came an informal meeting with the agency, an exchange of questions and answers that took in the risk assessment rather than a formal scientific advice meeting.
Preparation of the redaction package began in November 2023. The CHMP gave its positive opinion in February 2024, when the package was almost ready, and the redaction proposal was submitted in March 2024. It took only 10 days to validate, which the team put down to its preparation and to the absence of commercially confidential information. For many companies, validation sometimes involves a lot of going back and forth.
The European Commission decision approving the drug followed in April 2024. One last, minor question about personal data concerned IP addresses, and once it was resolved the agency posted the package on 26 June 2024.
The package met its timelines because the work started early rather than at the last minute, and because it was a team effort. Part of that effort was explaining Policy 0070 to the data protection officer, who had to sign the package off but came from the legal side rather than being a scientist or a writer. A company's data protection officer is responsible for what the company puts into the public domain.