¶ Who's involved?
In this section we will look at some of the technical roles needed to successfully get things running in more detail.
¶ IT staff or technical experts local to each participating data provider (institution)
In a consortium, most groups providing data will set up their own infrastructure and this will require local technical expertise. There can be a very wide range of skills and engagement of people based at each institution who will be setting up and maintaining the technical infrastructure. The different activities can also be split between individuals.
- Identify / acquire a system to host the software and data. This could be on the group's own systems, within their wider institution or from a 3rd party (e.g. AWS)
- Install and configure the software (e.g. set up accounts)
- Sort out networking issues such as opening the firewall, setting up a Fully Qualified Domain Name (the "internet address") for the server, obtaining a security certificate (to confirm the "identity" of the server to people connecting)
- Maintain and update the software on the server
¶ Examples of how this role can be filled
Some groups will have a central IT group that is detached from the scientific research and data management teams. This is a more “corporate” approach, where the IT staff have little understanding of the research. This can sometime involve many different people who have a specialist role from many "products" across a institution, such as a systems architect, data security officer etc. It may be necessary to have a ticket opened to provide support, which is then charged for. An advantage is that these teams can be familiar with providing services and support to others, and have expertise in setting up systems. This can come at a cost, with researchers who need DataSHIELD facing large bills.
At the other extreme you may have people with some technical skills embedded in the science/research team, or a data manager. They may not be experts in deploying and maintaining software, but they have a closer connection to the research and greater motivation to make sure that it can go ahead. It might be easier to contact them without having to go through a support ticketing system. And finally the cost to the research team might be less.
There is often a middle ground between these two extremes. For example, the a central IT group arrange for the server to be available and sort out the network access. Almost certainly someone at the institutional level will need to be involved for arranging connectivity to the outside world, setting up the "internet address" and sorting out an SSL certificate. Once these things are in place then someone in the research group can install the software, configure it, manage updates and so on.
¶ Things to consider about technical contacts
- What is their relationship to the research/data? Are they part of the research group or a central IT team who are generic to a large organisation? This will influence many things like their level of engagement and commitment, and also whether they just handle the basic install and maintenance or help with more detailed tasks like uploading the data and so on
- How is their time paid for? If they are in a central IT team they may charge hours to the project which can limit the support they provide.
- Can support be offered by a team rather than a single person, in case they change roles?
- How easily can they be contacted and how do they respond? If there is a problem with a server it can delay research for many users.
- What are their skills in terms of operating systems, Docker, using command line etc
- Hospitals have much stricter requirements around security e.g. won’t be keen on opening a firewall.
- How will you communicate? Just via email or do you need something with more flexibility like Slack?
In some cases we have seen several groups trying to share a server at one institution. At the moment the answer is that you have to have separate servers unless it is acceptable for the server admin to see all the data for both groups. This is not always acceptable, as it means one group might be losing direct control of their data. Also different consortia have different requirements e.g. one does central harmonisation another it is done locally, so different set ups might be required.
¶ Central consortium technical specialist
There will also need to be a central person who has a technical understanding of how the infrastructure works to take responsibility of:
- advising on an appropriate set up for each of the participating groups
- supporting each group in completing and maintaining their set up
- running a central analysis server if required
- hosting data on behalf of others who cannot set up their own infrastructure
- providing "images" for consortia where multiple different DataSHIELD configurations are needed
- using this wiki to help with some of these decisions...
¶ How do you convince people that it is secure, OK for GDPR and so on?
WP7????