Data Management Plan SNSF – Guidance on Applications

The data produced in this project will fall into [3] categories:

1. […] 
2. […] 
3. […]

Data in category 1 will be saved and documented in [...] format and will amount to approximately […TB]. Data in category 2 will be saved and documented in […] format and will amount to approximately […GB]. Data in category 3 will be saved and documented in […] format and will amount to approximately […MB]. 

The data are health records auto-generated by users of the application X. They are subjected to a contract with the company X.

All fields contain user observations and are entered manually, except for temperature which is measured by a Bluetooth connected thermometer.

Data fields per user (anonymised by X): User identifier; Age; Weight, Size.

Data fields per users per day of observation:

• Temperature and time at which temperature is taken,

• Cervical fluid quality (none, sticky, creamy, egg white, watery) and quantity (little, medium, lots),

• Cervix height (low, med, high), cervix openness (closed, med, open), cervix firmness (firm, med, soft),

• Sexual intercourse (protected or unprotected),

• Menstruation (light, medium, heavy), spotting, starting a new cycle,

• Custom data (notable predetermined fields are pregnancy test results or ovulation test results).

Data will be received in CSV format, and consists of the record of 2 million users. It will amount to maximum 1GB.

There will be two categories of data: NEW data from this project and EXISTING data from the FOEN Lake Monitoring
program.

The NEW data will consist of several file types, all CSV real number format, which are all organized along the same principle: matrixes of times series with various channels, each corresponding to a sensor (number of sensors varies from 1 to10) and very different length, as the sampling frequency varies by several orders-of-magnitudes.

1. 6 files of CO2, DO, PAR and temperature (24 files at a time; Figure 2), each file only 1 sensor (Delta = 10 min; continuous),
2. Thetis profiles corresponding to time series (equivalent to depth series) of 10 sensors (Delta = 1 s; 5-10 times per day).
3. 5 files of CO2 time series for short-term surface flux measurements (several files, one per month),
4. meteodata file (eight sensors; continuous),
5. T-Microstructure profiles files (6 sensors at 512 Hz; several files, once per month) and
6. excel files for individual chemical samples (such as alkalinity, sediment trap estimates, ect; sporadic).

The EXISTING data is already available (CIPAIS, CIPEL) in excel sheets with matrices for the individual samplings and a variable number of parameters (~10 to ~25). The EXISTING data will not be modified and remains with the organizations. We will keep a copy on our computers during the project. We anticipate the data produced in category 1 to amount to several hundred MB for the moored and profiled sensor files and ~100 GB for the T-microstructure profiles; the EXISTING data in category 2 is in the range of ~20 MB.

Reused data from Smith (2000, DOI: […]) and Miller (2011, DOI: […]) will be merged with the newly collected data.

No other pre-existing data will be reused. 

The reaction conditions will be recorded and collated using a spreadsheet application and named according to each generation of reaction as follows: YYYYMMDD_HHmm_ProjectW_ReactionX_GenerationY_ScientistZ.csv

The various experimental procedures and associated compound characterization will be written up using the [e.g., Royal Society of Chemistry (adapt to your own discipline)] standard formatting in a Word document. Each Word document will also be exported to PDF-A. The associated NMR spectra will be collated in chronological order in a PDF-A document.

All samples on which data are collected will be prepared according to published standard protocols in the field [cite reference]. Files will be named according to a pre-agreed convention. The dataset will be accompanied by a README file which will describe the directory hierarchy.
Each directory will contain an INFO.txt file describing the experimental protocol used in that experiment. It will also record any deviations from the protocol and other useful contextual information.
Microscope images capture and store a range of metadata (field size, magnification, lens phase, zoom, gain, pinhole diameter etc.) with each image.
This should allow the data to be understood by other members of our research group and add contextual value to the dataset should it be reused in the future.

The experimental records and observations are recorded by hand-written notes followed by digitization (scanning). The analytical data are collected by the instruments that generated them; they are processed by the native programs associated with the instruments. A periodic quality control process will be applied to remove errors and redundancies. Errors include for example incorrect handling and machine malfunction. The quality control process will be documented.

The quality of experimental records and observations will be controlled by repeating experiments.

For NMR and X-ray, the data collection is done through instrument standardised data acquisition programs. For E-chem, UV-Vis, IR, GC, GC-MS, lab-standardized protocols will be used.

All files produced during this project will be stored in our Electronic Laboratory Notebook (ELN) and Laboratory Information Management System (LIMS) openBIS.
In this ELN, each scientist has a personal folder where to organize projects and experiments. Each experiment is described in the electronic notebook and all data related to the experiment is directly attached to it, in so called “datasets”. Each dataset is immutable, thus different file versions are stored in the lab notebook in different datasets with a manually generated version number. Very large datasets (100s of TBs) are not directly stored in openBIS datasets, but they are linked to the experimental description using an extension to openBIS called BigDataLink. This works similarly to the git version control software, so every time changes are made to the data, these need to be committed to openBIS, which automatically keeps track of the versioning.

The data will be accompanied by the following contextual documentation, according to standard practice for synthetic methodology projects:

1. Spreadsheet documents which detail the reaction conditions.

2. Text files which detail the experimental procedures and compound characterization.

Files and folders will be named according to a pre-agreed convention [XYZ], which includes for each dataset, identifications to the researcher, the date, the study and the type of data (see section 1.2).

The final dataset as deposited in the chosen data repository will also be accompanied by a README file listing the contents of the other files and outlining the file-naming convention used.

Metadata will be tagged in XML using the Data Documentation Initiative (DDI) format. The codebook will contain information on study design, sampling methodology, fieldwork, variable-level detail, and all information necessary for a secondary analyst to use the data accurately and effectively.
It will be the responsibility of:

• each researcher to annotate data with metadata,
• the Principal Investigator to check weekly (during the field season, monthly otherwise) with all participants to assure data is being properly processed, documented, and stored.

Two types of metadata will be considered within the frame of the project X: (i) metadata corresponding to the project publications, and (ii) that corresponding to the published research data.

In the context of data management, metadata will form a subset of data documentation that will explain the purpose, origin, description, time reference, creator, access conditions and terms of use of a data collection.

The metadata that would best describe the data depends on the nature of the data. For research data generated in project X, it is difficult to establish global criteria for all data, since the nature of the initially considered datasets will be different, so that the metadata will be based on a generalised metadata schema as the one used in [e.g., ZENODO (gathered metadata depends on the chosen repository)] which includes elements such as:

• Title: free text
• Creator: Last name, first name
• Date
• Subject: Choice of keywords and classifications
• Description: Text explaining the content of the data set and other contextual information needed for the correct interpretation of the data,
• Format: Details of the file format,
• Resource Type: data set, image, audio, etc.,
• Identifier: DOI,
• Access rights: closed access, embargoed access, restricted access, open access.

Additionally, a readme.txt file will be used as an established way of accounting for all the files and folders entailed in the project and explaining how all the files that make up the data set relate to each other, what their file format is or whether particular files are intended to replace other files, etc.

For every data stream (sequences of identical data files) over the entire 2-year period of data acquisition a README File will be generated which contains: (a) the sensors used (product, type, serial number), (b) the temporal sequence of the sensors (time and location, sampling interval), (c) the observations made during maintenance and repairs, and (d) details on the physical units, as well as the calibration procedure and format. This is a standard procedure which we have used in the past.

In the data management system (openBIS ELN-LIMS), metadata are provided as attributes of the respective datasets. Based on the defined metadata schema, openBIS ELN-LIMS will be configured so that the required metadata is automatically assigned to datasets and / or manually provided by the researcher. Within openBIS we will provide metadata in line with the following metadata schema: […to be added by researcher…]

The project does not involve human or animal subjects. Therefore, no ethical issues are expected to occur during the generation of results from this project. None of the data collected or reused in this project is subject to a confidentiality agreement.

This project will generate data designed to study the prevalence and correlates of DSM III-R psychiatric disorders and patterns and correlates of service utilization for these disorders in a nationally representative sample of over 8000 respondents. The sensitive nature of these data will require that the data be released through a restricted use contract, to which each respondent will give explicit consent. An ethical authorization will be obtained from the cantonal ethics committee for this project.

The project respects all the constraints and requirements as laid down in the Swiss Federal Act on Data Protection.

Research in this proposal involves the use of animals of the species mouse (Mus Musculus). Animal studies will be preceded by multiple biochemical experiments in vitro and in cultured cells. Mouse experiments will only be used at advanced stages of investigations when few, specific and highly relevant questions can be addressed by a limited number of experiments.

The PI and the research team will work in conformity with all applicable rules, guidelines and principles such as the EU directive 2010/63/EU on the protection of animals used for scientific purposes, the Swiss federal law on animal protection (RS 455), the federal ordinance on animal protection (RS 455.1), and the federal ordinance on animal experimentation, production, and housing (RS 455.163). All animal experiments will only be initiated after having received the approval of the Cantonal and Federal authorities.

Details on animal usage

In performing the experiments, we strive to strictly adhere to the 3Rs principle of Replacement, Refinement, and Reduction.

• Reduction: Each experiment will be designed to use the minimum number of mice required to obtain statistical significance. For the proposed pharmacokinetic experiments, a total number of 24 mice will be required.

• Refinement: The animals will be housed in the animal facilities of EPFL, which meet international housing norms, and the animal health status is monitored by a certified veterinarian. To reduce stress and discomfort of the animals, all procedures will be performed only after animals are anaesthetized. After experiments animals will be euthanized. Also, as soon as animals show signs of severe discomfort and/or tumor burden during experiments, they will be euthanized by cervical dyslocation after being anaesthetized.

• Replacement: Alternatives for mouse experiments will be considered at all stages during the project. Whenever possible, these alternatives will replace the mouse experiments.

Training

All researchers and technicians working with the animals receive proper animal welfare training in conformity with DFE Ordinance 455.109.1 on ‘Training in animal husbandry and in the handling of animals’.

The PI and the research team will work in conformity with all applicable rules, guidelines and principles such as the EU directive 2010/63/EU on the protection of animals used for scientific purposes, the Swiss federal law on animal protection (RS 455), the federal ordinance on animal protection (RS 455.1), and the federal ordinance on animal experimentation, production, and housing (RS 455.163). All animal experiments will only be initiated after having received the approval of the Cantonal and Federal authorities.
Details on animal usage:
In performing the experiments, we strive to strictly adhere to the 3Rs principle of Replacement, Refinement, and Reduction.
Training: All researchers and technicians working with the animals receive proper animal welfare training in conformity with DFE Ordinance 455.109.1 on ‘Training in animal husbandry and in the handling of animals’.

Dataset X was obtained from the BAFU and is subject to a confidentiality agreement to keep information about the sampling locations secret. We are allowed to share this information among researchers involved in the project. The dataset is being stored in a location to which only project member have access. Please refer to Section 2.2 for technical details about access restrictions. All project members will be informed about sensitivity of this data and agree not to copy it to other places. This dataset and intermediate datasets containing the sampling locations will be excluded from the data package published along with the final report and replaced with instructions about how to obtain them from the BAFU.

All data are anonymised, and as such, we are in line with the Swiss Federal Act on Data Protection as described on the page of the Federal Data Protection and Information Commissioner (FDPIC). The anonymised data will only be published in line with the consent forms signed by participants. Moreover, we will adhere to the recommendations of the selected FAIR repository regarding upload and licensing of the anonymised data.

The data will be processed, managed, and analysed on […description of server infrastructure…], which is regularly and automatically backed up. Raw sequencing data is stored on the group storage on […e.g, the Euler cluster at ETH]. Only authorised persons (project members) will have access to the storage server via their password-protected institutional accounts. Since no personal or confidential data is produced or reused in the project, no special infrastructure or security measures will be necessary. Research data used in this project will be classified in line with the Directive on “Information Security at ETH Zurich” and marked accordingly. [For the directive, see the Directive on “Information Security at ETH Zurich”, Appendix 1b in particular could be relevant and helpful for classification]

All input data for analysis and output data from analysis will be shared in a GitLab repository [e.g., GitLab repository hosted by ETH Zurich’s IT Services, https://gitlab.ethz.ch] available to the project members. The same holds for the metadata about input and output data together with text file documentation for code. The systems from which these data are extracted by the company is only available to their employees. For security reasons, we do not share data or code in any other ways (e.g., by email). Research data used in this project will be classified in line with the Directive on “Information Security at ETH Zurich” and marked accordingly.
[For the directive, see the Directive on “Information Security at ETH Zurich”, Appendix 1b in particular could be relevant and helpful for classification]

Leonhard Med is the ETH secure scientific Data and IT platform to securely store, manage and process confidential research data [e.g., sensitive personal data in biomedical research]. Sufficient security is provided by this tool, i.e. strictly restricted access to authorized users, secure isolated storage and encrypted backup, shared or dedicated compute resources, logging and monitoring of user activity, strictly restricted access to trusted external internet sites, compliancy with the Leonhard Med Acceptable Use Policy (https://rechtssammlung.sp.ethz.ch/Dokumente/438.1.pdf). 
Data analysis of offline data (i.e., processing that was not performed in real time) will be performed in the Leonhard Med platform. If the analysis requires software that is not available to the moment in Leonhard Med, computed statistical maps on the individual level (individuals cannot be identified) will be transferred to a dedicated computer where the analysis can be performed. Only internal research personnel will have access to Leonhard Med and will be trained for it. General authentication and authorization at ETH Zurich are handled by the Identity- and Access Management System of the central IT-Services at ETH.
Specific guidelines apply for using the Leonhard Med Cluster at ETH Zurich to securely store, manage, compute on and share confidential research data (https://ethz.ch/services/en/it-services/it-security/guidelines.html).
Because we will deal with personal, sensitive data, project members will be provided with and sign confidentiality agreements. Access to personal/sensitive data will be restricted.
Storage media and safety back-ups will require password access to prevent misuse. The applicant and the supervisor are responsible for secured access to datasets as well as for safeguarding the code keys. 
The level of the data availability risk is low, the level of data integrity risk is high, and the level of data confidentiality is high.
Regarding anonymization / encryption: All sensitive data will be encrypted at rest (e.g., on file system when not in use, in backups) and in transit and keys will be managed only by the [name of data controller]. Pseudonymized data are still sensitive personal data and there will be a concordance table stored at the data controller. All sensitive, personal data will be handled securely (concordance table will be encrypted as it is not actively used). We will follow the policy and available procedures of Leonhard Med for ensuring data security during transfer. Leonhard Med offers a specific secure data transfer process in encrypted form, via encrypted channels.
Regarding access rights: Sensitive personal data will be accessible only to the following people working in the project: [name person A] [name person B]. The grantee and the Principal Investigator of the project will be responsible to ensure compliance with these defined access rights. 
Regarding storage and back-up: All data will be backed-up on a regular basis [good practice is minimum daily] and access to backup media will be managed according to data access rules. All damaged media containing sensitive data will be physically destroyed. Research data used in this project will be classified in line with the Directive on “Information Security at ETH Zurich” and marked accordingly.
[For the directive, see https://rechtssammlung.sp.ethz.ch/Dokumente/203.25en.pdf, Appendix 1b in particular could be relevant and helpful for classification]

The data we are generating, processing and storing in this project does not pose a particular data security risk. Day-to-day work is conducted on standard-issue workstations in the ETH-environment with standard enterprise-grade access control. The ETH network is a secured system following the best practices in terms of identity management and central storage facility has redundancy, mirroring and is monitored. At different stages, data will be stored in the Eawag Institutional Collection (see section 1.3). This system is accessible only from within the Eawag network and is comprised of several virtualized Linux systems that receive real-time security patches. Access control is handled according to recognized best practices of server administration.

“Notoriously Toxic”, NEH ODH Start-up Grant, Level 1, https://www.neh.gov/files/dmp_from_successful_grants.zip

Research records will be kept confidential, and access will be limited to the PI, primary research team members, and project participants. Data will be housed on a local server controlled by the PI, and will be accessible via SSH and VPN. Data containing identifiable information, or information covered by an NDA, will be held in an encrypted format (symmetric, AES256, key on local server, passphrase only known to PI and primary research team members).

All data generated in the project will be stored in our open- BIS ELN-LIMS. This operates in a client-server model, which is installed and maintained by the ETH Zurich IT services on ETH Zurich infrastructure. Researchers can access openBIS via any of the most common web browsers. openBIS requires user authentication with ETH Zurich credentials and it provides user right management, so that different users can have different access to all or different parts of the system, as required. Below is a description of the default openBIS roles, which can be modified upon request:

1. Instance admin. Has full admin powers. Can customize settings, create, modify and delete entities, assign user roles, create data spaces.
2. Instance observers. Has read-only access to everything in openBIS.
3. Space admin. Can create, modify, delete entities and assign roles only within a given data space.
4. Space power user. Can create, modify and delete entities only within a given data space.
5. Space user. Can create and modify entities only within a given data space.
6. Space observer. Has read-only access limited to a given data space.

openBIS does not offer any specific option for sensitive data, but the data will be encrypted prior to upload to openBIS. Furthermore, all operations on the system (incl. which users log in and when) are logged, so that it is fully transparent who did what to the data and when.

The data stored in openBIS is physically located on a NAS (network attached storage) provided by the ETH Zurich IT Services. The access to the share’s data is governed by the latest security best practices and only a limited number of employees of the ETH Zurich IT services have access to that share.

The collected data is suitable for sharing. They are observational [or: experimental] data and could be used for other analyses or for comparison in future studies. Reuse opportunities are vast. For this reason, the project participants aim to allow the widest reuse of the data and will release them under a Creative Commons public domain dedication (CC0) [alternative: creative commons CC-BY licence]. With regards to data sharing, there are no restrictions due to copyright or intellectual property rights.

All data used in the project is owned by the collaborating company. A contract has been signed by both parties stating the project’s aims, methods, ownership rights, and how the project outcomes will be used.

This project is being carried out in collaboration with an industrial partner. The intellectual property rights are set out in the collaboration agreement. The intellectual property generated from this project will be fully exploited with help from the institutional Technology Transfer Office. The aim is to patent the final procedure and then publish the work in a research journal and to publish the supporting data under an open Creative Commons Attribution (CC BY) license.

The research is not expected to lead to patents. Other Intellectual Property Rights (IPR) issues will be dealt in line with the institutional recommendation. As the data is not subjected to a contract and will not be patented, it will be released as open data under Creative Commons CC0 Public Domain Dedication.

The source code for analysis will most likely utilize the GNU Scientific Library (GSL), which is licensed under the GNU General Public License (GPL). Therefore we will make our analysis software available under the GPL as well.

All data are stored on the standard departmental ETH server. If the data sets are exceeding a reasonable amount it is switched to the Network Attached Storage (NAS) also hosted by ETH. Both, standard ETH server and NAS include automatic daily backups and are maintained by ETH Zurich’s IT Services.

[Example 1 +] All data will also be uploaded to and stored on GitLab for version control [e.g., GitLab repository hosted by ETH Zurich’s IT Services, https://gitlab.ethz.ch]. This holds for both the raw input data that will be processed for analysis and any output data from the analysis.

The data will be stored via using the following resources:

• For general storage, ETH’s server infrastructure (for aggregated, non-personal and non-sensitive data) and Leonhard Med (for personal, sensitive data) will be used, with standardized, daily backup procedures.
• A copy of the non-personal and non-sensitive data will also be stored on local hard-drives.
• For code storage and version control, we will use GitLab. (https://gitlab.ethz.ch/).

Data stored on the ETH server infrastructure and Leonhard Med will be automatically backed-up daily and storage in hard drives will be backed-up weekly. Insertions and changes made in GitLab are tracked and versions are kept automatically. The team will be instructed to follow a checklist for storing and backing up data, standardizing the procedure.

All our data will be uploaded to our Electronic Laboratory Notebook. The data is stored on institutional storage facilities and it is set up by our IT support to be automatically backed up daily.

The ETH centralized file storage service follows the best practices and standards regarding storage, for instance high availability, multiple levels of data protection, partnership with providers for support. The service is managed centrally by by ETH Zurich’s IT Services and ensures security, coherence, pertinence, integrity and high-availability.

Two distinct storage locations can be found on the ETH campus with replication between the two. (Please note that these two different storage options correspond to different payments.) Physical servers’ pairing and clustering guarantees local redundancy of data. Moreover, volume mirroring protects data in case of disaster on the primary site. The copy is asynchronous and automatic and runs every two hours.

The file servers are virtualized for separation between logical data and physical storage, RAID groups ensure physical storage protection: data is split in chunks written on many disks with double parity. Moreover, volume snapshots are used and can allow user restoration of previous versions if need be. For specific needs, optional backup on tape can also be done.

Access to the data is managed by the owner of the volumes through the identity management system of ETH. Any person who needs access to data has therefore to be a registered and verified user in the identity management system.

openBIS uses a postgres database that stores all metadata. This database is backed up (“pg_dump”) every night with a 7 days retention of the dumps and fully backed-up twice a week with a backup retention of 20 days. The full backup procedure includes a point-in-time recovery that allows a finer granularity (up to minutes) of data recovery in case of a disaster. The database backup is stored on the NAS (network attached storage) provided by the ETH Zurich IT services. The same NAS is used to store the data uploaded to openBIS. This network attached storage is snapshot every night with a 7 days retention, and data is backed up on a proprietary tape library with a retention of 90 days.

Data which is no longer actively needed is moved to the long term storage (i.e. tapes). The tape library where openBIS moves the data has a read-only replica in a different geographical location in order to minimize any data loss.

*For data linked to openBIS with the BigDataLink tool, please provide details of the data location and back-up.

Original notebooks and hardcopies of all NMR and mass spectra are stored in the PI’s laboratory. Additional electronic data will be stored on the PI’s computer, which is backed up daily. Additionally, the laboratory will make use of the PI’s lab server space at institution’s storage facility for a second repository of data storage. The PI’s lab has access to up to 1 terabyte of information storage, which can be expanded if needed.

All the project data will be stored using the institution’s collaborative storage, which is backed-up on a daily basis.

We will preserve the data for 10 years on ETH’s servers and also deposit it in an appropriate data archive at the end of the project [e.g., disciplinary data repository/archive, ETH Research Collection (with long-term preservation in the ETH Data Archive, or Zenodo, see examples in section 4.1 below)]. Where possible, we will store files in open archival formats, for example, Word files converted to PDF-A or simple text files encoded in UTF-8 and Excel files converted to CSV. In case this is not possible, we will include information on the software used and its version number.

This research project is an industrial collaboration. The data are owned by the collaborating company and constitutes a valuable resource in the highly competitive industry in which they operate. For this reason, the original data cannot be preserved in a public data archive. Instead, the original raw input data owned by the industrial partner is preserved by the collaborating company. All aggregated, non-confidential parts of the data will be submitted to the [name of the archive, e.g., disciplinary data repository/archive, ETH Research Collection (with long-term preservation in ETH Data Archive), or Zenodo] to be kept for a minimum of 10 years. Where possible, we will store these files in open archival formats. E.g., Word files will be converted to PDF-A or simple text files encoded in UTF-8 and Excel files will be converted to CSV. In case this is not possible, we will include information on the software used and its version number.

The data will only be stored in an appropriate archive once they are fully anonymized and only in line with the consent forms signed by participants. Moreover, we will adhere to the recommendations of the selected FAIR repository regarding upload and licensing of the anonymized data.

Text documents and scans will be stored as PDF/A files or unformatted ASCII files with file name extension .txt. Excel files will be stored in csv  format. Files from the statistics software R will be stored as ASCII files. All these formats are recommended for long-term archiving. The ETH Data Archive assesses the long-term readability of these file formats as high and takes measures for long-term usability.

Data collected in this project will be released under a Creative Commons public domain dedication (CC0) [alternative: creative commons CC-BY licence] in the ETH Research Collection [alternatives: appropriate subject specific repository XY; Zenodo; others…] as a FAIR data repository. Data in the repository will be stored in accordance with the SNSF's data policies. Data underlying publications will be shared at the point of publication of a journal article or book chapter, while all remaining data will be made available at the end of the project period.

Datasets deposited in the Research Collection will be given a Digital Object Identifier (DOI). Data deposited in the Research Collection with individual file sizes of less than 10 GB are also archived in the ETH Data Archive for long-term preservation. The DOI issued to datasets in the repository can be included as part of a data citation in publications, allowing the datasets underpinning a publication to be identified and accessed. Metadata about datasets held in the Research Collection will be publicly searchable and discoverable and will indicate how and on what terms the dataset can be accessed.

This research project is an industrial collaboration. The data are owned by the collaborating company and constitutes a valuable resource in the highly competitive industry in which they operate. For this reason, the original data cannot be made publicly available. As far as contractual obligations with the industry partner permit, metadata-only entries that describe the datasets will be made available in the ETH Research Collection [alternatives: appropriate subject specific repository 'XY'; Zenodo; others…] as a FAIR data repository. In that way, other researchers can find the dataset and get information about it without having direct access to the protected data.

Patients have been informed and provided consent with a signed consent form regarding the publication of their anonymized data in a public repository. The collected patient data will be fully anonymized before publication. The anonymized data will be released under the standard usage licence (rightsstatements.org/page/InC-NC/1.0/) in the ETH Research Collection [alternatives: appropriate subject specific repository XY; Zenodo; others…] as a FAIR data repository. Anonymized data underlying publications will be shared at the point of publication of a journal article or book chapter, while all remaining data will be made available at the end of the project period.

The collected data contains genetic information that could easily identify individual persons. Therefore, the respective data must be protected and cannot be published in a repository. As far as the metadata do not contain any confidential or personal information, metadata-only entries that describe the datasets will be made available in the ETH Research Collection [alternatives: appropriate subject specific repository XY; Zenodo; others…] as a FAIR data repository. In that way, other researchers can find the dataset and get information about it without having direct access to the personal data.

Some of the ongoing data will be shared on [Researcher1]’s Github repository (results and code from the project, data from twitter searches). Major revisions of this page will be baked up using the Github-Zenodo connection (see: https://guides.github.com/activities/citable-code/). All other data we will be published on Zenodo under CC0 Public Domain Dedication.

We chose Zenodo because it supports the FAIR principles (http://about.zenodo.org/principles/). Zenodo implements long-term preservation features, notably bitstream preservation.

For this project, the National Geoscience Data Centre (NGDC) (see http://www.bgs.ac.uk/services/ngdc/home.html) is the most suited repository. As it is adapted to geodata, it facilitates storage and allows interactive geographical search. In addition, many other researchers in our field are familiar with it.

This repository requires the deposition under Open Governement Licence (see : http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/), which demands attribution when the data is reused (our dataset must by cited, similarly to the CC BY license).

The project does not involve usage of any sensitive data. Therefore, no special limitations to data use or reuse are necessary.

The data used in this project will be handled in line with the respective classification level [strictly confidential and/or confidential, see DMP section 2.2.] that has been selected in accordance with the Directive on “Information Security at ETH Zurich”. All data is aggregated, anonymized and processed to be compliant with data privacy laws. As described, the original data will nonetheless not be made available due to strict confidentiality. The data ownership lies with the partner company.

The data used in this project will be handled in line with the respective classification level [strictly confidential and/or confidential, see DMP section 2.2.] that has been selected in accordance with the Directive on “Information Security at ETH Zurich”. All data is aggregated, anonymized and processed to be compliant with data privacy laws. [Data that cannot be fully anonymized cannot be published. Anonymized data can only be published to the extent covered by informed consent.]

[Ooptional addition:] Personal data will be anonymized before diffusion based on the recommendations from the Federal Act on Data Protection (FADP) (https://www.edoeb.admin.ch/edoeb/en/home/latest-news/aktuell_news.html#-2053438021, accessed 01.11.2022). The package SDC-Micro (https://cran.r-project.org/package=sdcMicro) will be used to assess the risk of identification: we will make sure that each data set has a k-anonymity of 3 at least.

The extensive household survey about water-born diseases poses severe challenges with regard to anonymization. Pseudonymization is inufficient to guard against the identification of individual households by an inference that uses other available information.

Therefore we will be only able to publish summary statistics together with the associated article. If a sufficiently anonymized dataset turns out to still hold scientific value, we will publish it no later than one year after completion of the project.