Hi all,
Thought it would be interesting to raise some comments I have from my first few weeks of using Central 1.0 in the context of operating a multi-user service for ODK at my research institute.
I'm sure that some of these are already things that have been thought about, but here they are...
-
MOST IMPORTANT The sitewide administrator (SA) can see all the data in all the projects (unless encrypted) and I am confident that we will break all kinds of laws and ethics if we run a service this way. I certainly neither need, nor want, nor am legally entitled under EU law or local study ethics/consents to see sensitive study data. My SA role is really just to create and archive projects, to assign a project admin (PA) and importantly to make key checks about whether people are doing things like encrypting their data. Having an SA view of a project that gives statistics on things like a list view of forms, a summary of whether project or individual forms are encrypted, summary of #submissions, last submission dates, size of database etc is what we need as SA. Of course if the SA was also a member of a project they could be added by the PA using the project roles system, but for the most part I feel that the SA should be included as a member of the project team by invitation and not by default.
- From the web user (WU) management system, there's nothing to tell the SA which project(s) each user has a role in. This is really important if we are to track which users have access to the system and remove users when no longer allowed on the system.
- The ability to put creation dates on WU manager would be useful. i.e. to see when someone was added as a WU without having to refer to the system log.
- Current ability of a PA to add absolutely any web user from total web user pool to a project is not IMHO a good idea - If ability to create a web user is restricted to the control of the SA, then allocation of web users to specific projects should be similarly controlled. If someone accidentally invited the wrong WU in to their project, you'd end up with data security breach.
- Project level encryption cannot be deactivated, nor password changed. I know that reversing the encryption is on the roadmap somewhere, but the inability to change the security password if compromised feels like a weak spot and urgent issue. I guess that these are linked problems!
- Server audit log is excellent, but would be more useful if individual PAs could access data for their own project. This is crucial for people running clinical trials.
- Ability of PA to download project level server log would be very valuable for audit purposes.
- There's no function to limit data download (and decrypt) to a specific date range. For any project with large data set and particularly those with file attachments (images etc) the size of the data download will get very large indeed. Because you can't use Briefcase to decrypt project level encryption, you run the risk that if your data collection grows unexpectedly, you make it hard to download the data using an alternative method. Control using date-time system would be immensely useful as we saw previously with huge deployments that used Briefcase.
Thanks all for your thoughts.
Chrissy h