Add a "consent withdrawn" subject removal tool

[ericearl]

What would you like to see added?

This feature would prevent dataset deletions and re-uploads. The basic idea is to have a subject removal tool for if a subject withdraws their consent to share their data. This tool or feature would allow a dataset curator to either replace or delete files and purge data from every file associated with a subject as either a data file or a row in a TSV.

Alternatives

Alternatively, I suppose you could allow users to forward old DOIs to new dataset uploads themselves. This removes the nice history established by prior uploads and change logs though.

Do you have any interest in helping implement the feature?

Yes, but I would need guidance

Additional information / screenshots

• This feature might go well with the issue #2701.
• I'm imagining it would be best if this feature worked with Git history purging as well. I know Git history revision is a delicate thing, but we are informatics experts and should be able to figure it out with some effort together.
• Last thought (for now), it would be amazing if you just entered a BIDS participant_id and all files containing that participant_id in either the filename or in TSV contents could be flagged for a purge.

[effigies]

There are significant challenges with a plan to memory hole subjects while retaining a dataset's history. Technically, you introduce difficulties with updating a dataset that has already been cloned to ensure smooth updating to the rewritten history. More importantly, a researcher who reports that they analyzed dataset X at version Y would no longer be reporting an unambiguous provenance, and there would be no way in principle to demonstrate that the only deviation from version Y (first time round) and the current version Y is the removal of whole subjects. The entire concept of dataset history would be compromised.

(As an aside, the immutability of history protects against vandalism; a compromised account or disgruntled coauthor can create bad new versions, but cannot currently purge an entire subject or dataset without administrator cooperation.)

If this is implemented, I think the cleanest approach would be to create a new branch with cleaned history. Once examined and approved, that branch would be transitioned to a new dataset and the old dataset deleted and redirected to the new dataset. This would formalize the current process without requiring reupload.

It is not clear to me, however, that the current process should be formalized and made simple. Subjects are consented to share their data publicly, and they should be informed of the challenges related to withdrawing consent. The Open Brain Consent language includes:

If you change your mind and withdraw your consent to participate in this study (you can call \<PI name> at \<phone number> to do this), we will not collect any additional data about you. We will delete your data if you withdraw before it was deposited in the database. However, any data and research results already shared with other investigators or the general public cannot be destroyed, withdrawn or recalled.

The technical impossibility of performing a verifiable recall of data needs to be understood and accepted at the time of consent. I would recommend that studies that do not receive consent on these terms not publish their data in OpenNeuro. If you have received this informed consent, then making a best effort to cease distribution within the technical capabilities of the database would seem to satisfy your obligations to participants.

[ericearl]

@effigies That is a super-well-put response to my issue, thank you! I really like your point about consent language and considering whether OpenNeuro is the right repository given your study's consent language. The issue we are facing right now should probably not require a "consent withdrawn" mechanism on OpenNeuro, but either a change of consent language for further studies or a change of destination repository.

This also goes to show what a success OpenNeuro is, where people would rather put their data here than struggle with other platforms' upload processes.

[Arshitha]

@effigies Thanks for the comprehensive response! I had not considered

More importantly, a researcher who reports that they analyzed dataset X at version Y would no longer be reporting an unambiguous provenance, and there would be no way in principle to demonstrate that the only deviation from version Y (first time round) and the current version Y is the removal of whole subjects. The entire concept of dataset history would be compromised.

but I can see how changing git history would go against the goal of transparency and reproducibility.

And I agree that changing language in the consent form is probably the most efficient. Thank you also for sharing the open brain consent resource too!