Can redcapAPI apply lower level of data export rights than the user's ?

[tobadia]

Hello all,

This question may actually fall in the scope of the 'REDCap API' itself, but I'm wondering if there's any way for a user who has 'full data' export privileges to actually query the DB and request, say, a de-identified version of the data ? In other word, can I request from the API a dataset that would match the export for lower privileges than I have ?

Subsequent question: if the REDCap API does not allow this, could this be considered a feature request (e.g. dropping columns and/or hashing some other ones) ?

Thanks !

[spgarbet]

This has been asked for internally before and the request hasn't gotten off the ground. There's a lot of complexity in de-identification of data, and I suspect no one wants the risk of saying it does that and missing something. One can always request fewer columns via fields or drop_fields.

The data type conversion callbacks could be used to specify columns to hash. Just thinking through this idea, an argument could be added of columns to hash. Maybe add hash_fields and a hash_algorithm (with a suitable default).

[nutterb]

If the user has access to editing user rights, they could change the user export privileges before exporting and then reset them.

But this will only work if they have permissions to change user rights.

[tobadia]

Yeah, I get that it's quite a big deal to offer such a feature because there's no room for a failure...
For now, in my own pipelines (that rely on redcapAPI for exporting, but that's it) I usually bundle in a dummy deidentify_dump(rcon, x) function that reads rcon$metadata(), isolates the field names where identifier == "y" and drops the corresponding column from x.

A meeting earlier today made me think "maybe that should be bundled in before calling the API for a dump", hence that thread. I hadn't though of the drop_fields, that's pretty much similar to my pipeline, I guess.

@nutterb it works if you have access to user rights... and also is not convenient when you have routine pipelines (some that require everyting to be available e.g. for clarification queries, and some that do not require identifiers e.g. routine analysis). The less I touch configs, the better :)

Anyway, if the topic comes back on the table someday, two suggestions:

• simple de-identification relying on metadata can quite easily drop columns
• more complex pseudonymization could be passed a list of columns that should be hashed (in a fashion as @spgarbet suggested... which was on my todo list for today but I won't have time to do it right now, in the end)