#  General information

##  MRI and ultrasound Robotic Assisted Biopsy (MURAB)

The MURAB project has the ambition to revolutionise the way cancer screening
and muscle diseases are researched for patients and has the potential to save
lives by early detection and treatment. The project intends to create a new
paradigm in which, the precision of great medical imaging modalities like MRI
and Ultrasound are combined with the precision of robotics in order to target
the right place in the body. This will be achieved by identifying a target
using Magnetic Resonance Imaging (MRI) and then use a robot with an ultrasound
(US) probe to match the images and navigate to the right location. The project
has received funding from the European Union’s Horizon 2020 research and
innovation programme under grant agreement No 688188.

Partner organisations include the University of Twente (UT), Zorggroep Twente
(ZGT), RadboudUMC, University of Verona (UV), Medical University of Vienna
(MUW), KUKA, and Siemens. The project will be performed during four years with
start date on January 1  st  , 2016\. All institutions are involved in data
management, but the main responsibilities for data management are supervised
by the consortium leader from the UT, as shown in Table 1.

Table 1: Institutions and their main responsibilities for data management  
  
<table>  
<tr>  
<th>

**Institution**

</th>  
<th>

**Responsibility**

</th> </tr>  
<tr>  
<td>

**UT**

</td>  
<td>

Vincent Groenhuis, Françoise Siepel – DMP document authors

Different members of MURAB team of Robotics and Mechatronics (RaM) – DMP
implementation, server setup.

</td> </tr>  
<tr>  
<td>

**Verona university**

</td>  
<td>

Research and Dissemination

Marta Capiluppi – Dissemination coordinator

MURAB team of Verona – Monitoring DMP implementation.

</td> </tr>  
<tr>  
<td>

**ZGT, RadboudUMC,**

**Medical University of Vienna**

</td>  
<td>

Medical investigations; responsible for anonymization of data collected at
hospitals and transferring medical data to researchers according to this DMP.

</td> </tr>  
<tr>  
<td>

**SIEMENS**

</td>  
<td>

Support and business advisor during the scope of this project.

</td> </tr>  
<tr>  
<td>

**KUKA**

</td>  
<td>

Technical and business support during the scope of the project.

</td> </tr>  
<tr>  
<td>

**All partners**

</td>  
<td>

make use of DMP plan, sharing data through server etc.

</td> </tr> </table>

##  Laws, policies, contracts and agreements to comply with

The MURAB data management Plan needs to comply with the following laws,
policies, contracts and agreements:

EU:

  * Horizon2020 project, participating in Open Access Data pilot. 

  

Guidelines:

http://ec.europa.eu/research/participants/data/ref/h2020/grants_manual/hi/oa_pilot/h2020-hioa-
data-mgt_en.pdf

  * Grant Agreement number 688188, available in the Horizon2020 Participant Portal under ‘Document library’. 

  

  * Consortium agreement related to this Grant Agreement, available at each individual partner’s document library. 

  

Dutch:

  * Law protection personal data (Wet bescherming persoonsgegevens): 

  

https://autoriteitpersoonsgegevens.nl/nl/over-privacy/wetten/wet-bescherming-
persoonsgegevens

  * FMWV Code of conduct for medical research of the Dutch biomedical research community (Gedragscode gezondheidsonderzoek van de Nederlandse biomedische onderzoeksgemeenschap): 

  

http://www.giantt.nl/gedragscode%20gezondheidsonderzoek.pdf ▪ UT data policy
and research datamanagement:

https://www.utwente.nl/ub/dienstverlening/MAIN/onderzoeksdatabeheer/

#  Data Collection

##  Data description

There are several types of data that will be collected and shown in Table 2.
At baseline all research data, as described in the table below, will form a
single dataset. The name of this dataset is “MURAB research data”.

Table 2: MURAB research data  
  
<table>  
<tr>  
<th>

**Type of data**

</th>  
<th>

**Format**

</th>  
<th>

**Software**

</th>  
<th>

**Data size/growth**

</th>  
<th>

**Specific character**

</th> </tr>  
<tr>  
<td>

**New MRI scans taken at various locations (UT and hospitals), from dummies,
phantoms, and patients.**

</td>  
<td>

DICOM (as produced by MRI equipment).

</td>  
<td>

The MRI computer is used to generate the DICOM data.

DICOM software

(available on WWW) can read and display the datasets, for example 3DSlicer or
3DimViewer.

</td>  
<td>

One slice with a size of

1MB on average

(range 0.1-50MB); one scan contains around

100 slices (100MB av-

erage); about 10 scans are taken per session (one session consists of scanning
one patient multiple times on one daypart), resulting in 1GB of data per
session on average.

Scanning 100 sessions : 100GB of DICOM data on average, with maximum size of
5TB.

</td>  
<td>

Phantom models (exvivo) and possibly patients (in-vivo).

Target: breast cancer diagnosis, muscle diseases.

Patients: personal data is collected in hospitals (see below for anonymization
procedure).

</td> </tr>  
<tr>  
<td>

**Existing MRI and/or ultrasound datasets of several patients,**

**retrieved from hospitals and/or databases.**

</td>  
<td>

MRI: DICOM

Ultrasound: depends on dataset, could be DICOM or a generic image format like
jpg/ png.

</td>  
<td>

DICOM: See above. Ultrasound: depends on format; 3DSlicer can handle many
formats.

</td>  
<td>

About 1GB per session. 10 to 100 sessions, so 10-100 GB

total

</td>  
<td>

Anonymized breast scans of patients, all ages, retrieved from hospital’s
databases and/or other data sources.

</td> </tr>  
<tr>  
<td>

**Ultrasound scans with probe position data, and additional sensory data of
phantoms and patients.**

</td>  
<td>

Ultrasound: a raw data is always processed first. Processed data format could
be

DICOM or other format depending on hardware and processing software used in
the different project stages.

Coordinate and sensor data: coupled to scans, either embedded as metadata in
DICOM or in separate data file(s) linked together. Coordinate data stored in
comma-

separated values

(CSV) format.

</td>  
<td>

Ultrasound data recorded by own software (in case of research hardware), or
pro-

cessed by off-the-shelf system.

Self-written software to record and process sensory data.

</td>  
<td>

Continuous ultrasound scanning results in multiple frames per second, each
frame has multiple KB’s of data so one session may end up in file sizes in the
order of 10 GB’s per case.

Single image ultrasound scanning: order of 10 MB per session.

</td>  
<td>

Ultrasound scans of breast phantoms and patients, linked to probe position and
orientation data from the robot arm. Personal data is collected in hospitals
(see below for anonymization procedure).

</td> </tr>  
<tr>  
<td>

**Segmentation data of MRI/Ultrasound scans.**

</td>  
<td>

List of features in a text file, exact format depends on process.

TBD

</td>  
<td>

MATLAB, Mevislab, 3D slicer, 20-sim, Modelica, own software and/or other
software packages (TBD)

</td>  
<td>

In the order of 1-10 MB per session.

</td>  
<td>

Segmentation data mainly consists of landmark positions that can be used to
combine MRI and US together.

</td> </tr>  
<tr>  
<td>

**3D volume modeling data with elastography information, generated from MRI
and tracked ultrasound datasets.**

</td>  
<td>

TBD

</td>  
<td>

See above

</td>  
<td>

Around 0.1GB per case, depending on

level of detail

</td>  
<td>

Coupled with

MRI/US/Elastography data of the same phantom or patient. Elastography
generated from combinations of tracked ultrasound scans and pressure sensor.

</td> </tr>  
<tr>  
<td>

**Biopsy needle insertion accuracy/deformation measurements.**

</td>  
<td>

TBD

</td>  
<td>

See above

</td>  
<td>

1-100 MB per case

</td>  
<td>

Coupled to a 3D volume model, with preoperative path planning, this processed
data shows the effect of needle insertion in

the phantom or patient, in terms of qualitative tissue deformations

</td> </tr> </table>

A special subgroup of data consists of design files, software code,
organizational documents, pictures and videos for informative purposes. These
are not research data in the sense of observational, experimental, simulation,
derived or compiled data (Table 3). Still, such data has to be stored and
back-upped to be useful during the project, so this is described below. The
name of this dataset is “MURAB nonresearch data”.

Table 3: MURAB non research data  
  
<table>  
<tr>  
<th>

**Type of data**

</th>  
<th>

**Format**

</th>  
<th>

**Software**

</th>  
<th>

**Data size/growth**

</th>  
<th>

**Specific character**

</th> </tr>  
<tr>  
<td>

**Design files, program code**

</td>  
<td>

Depends on software, e.g. C++ for program code, Solidworks / FreeCAD for 3d
de-

sign files

</td>  
<td>

Development and

CAD software

</td>  
<td>

1GB total

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Organizational files**

</td>  
<td>

MS Office, Google docs

</td>  
<td>

</td>  
<td>

1GB total

</td>  
<td>

Documents, spreadsheets

Some partners cannot access Google docs

</td> </tr>  
<tr>  
<td>

**Multimedia**

</td>  
<td>

Common video and audio formats, such as JPG, PNG, MP4 etc.

</td>  
<td>

Generic audio/video editing software, like Windows photo viewer

</td>  
<td>

1-10GB per video, 0.11GB per photo album. With 10 videos and 20 albums: up to
140GB needed.

</td>  
<td>

Video and photo collections about various parts of MURAB research.

</td> </tr> </table>

##  Procedures for anonymization of patient data at hospitals

All data files are coded by using random numbers as subject codes. Linkage
information connecting names to codes, will be stored separately from the
coded data in a secured cabinet and will be destroyed ten years after
completion of the study. Pseudonymization protocols will be applied, and all
data will be stored at a secured server.

The UT anonymization procedures are already covered by pseudonymization:

\- deleting or masking _personal identifiers_ , such as _name_ and _social
security number_ , - suppressing or generalizing _quasi-identifiers_ , such as
_date of birth_ and _zip code_

The location of privacy-sensitive data will be restricted to the hospital and
its access is managed by existing policies of the respective hospitals in The
Netherlands (ZGT, RadboudUMC) and Austria (MUW). All privacy-sensitive data is
anonymized before sending to researchers according to existing procedures,
after which the data is basically safe for publication and patient identity
will not be traceable.

##  Anonymization protocols for each hospital

Specific hospital guidelines are described below.

###  RadboudUMC data protocol

All data is collected and processed into Castor EDC by the investigator.
Sources of data are electronic patient system for patient, demographic,
laboratory, pathological, and follow-up data. Data collected regarding the
biopsy procedure will be collected during the procedure on paper CRF's. The
paper CRF will be dated, signed and scanned. They will be kept as a pdf file
in the data folder. This data will be entered in the Castor database.

Statistical procedures will be performed in SPSS. The used data will be
imported from CASTOR EDC and locked by storing it on CD ROM.

The statistical analyses and lists of codes will be locked after completion by
storing it on CD ROM.

Data is securely saved on the Castor server. The scanned paper CRF's together
with the statistical analysis files are kept in the data folder on the server
of the Radboud UMC, on the account of the investigator. The paper CRF's are
stored in the locked cabin of the investigator.

The code lists are kept on the server of the Radboud UMC, on the account of
the investigator.

Upon archiving, the paper CRFs will be archived in the secured archive
facilities of Radboud UMC. All CD-roms be kept in the secured cabin in the
PI's office. All data will be removed from folder in the investigators drive
and from Castor EDC database.

The data is coded: The first letter of the prenom combined with the 2 first
letters of the last name are the code used for study patients. All study
patients will also be assigned a study number.

Access to the code list folder is limited to the creator of the folder (data
manager), the PI and the investigator.

###  ZGT data protocol

The regulations of the “FMWV Gedragcode Gezondheidsonderzoek,” as authorized
by the College Bescherming Persoonsgegevens, will be adhered to.

In particular: medical data will be anonymized by ZGT before transferring them
to the researchers. Researchers working with this data, also have to follow
the “FMWV Gedragcode Gezondheidsonderzoek”. Researchers are not allowed to
perform operations on data that may reveal personal identities.

###  MUW data protocol

All data are stored in a PACS. Externals have no access.

If data is needed for research purposes, then it will be anonymized first
before sending it to the researchers. Also, a data transfer agreement will be
set up which has to be signed be partners.

#  Data Storage and Back-up

##  Storage and back-up

In this section, the data storage methods and back-up systems are described.
This applies for both “MURAB research data” and “MURAB non-research data” (see
table 4).

Table 4: Type of data and storage  
  
<table>  
<tr>  
<th>

**Data**

</th>  
<th>

**Storage medium and location**

</th>  
<th>

**Backup location, frequency, RPO and RTO**

</th> </tr>  
<tr>  
<td>

**Raw data generated by different research groups within the consortium in
experiments on phantoms**

</td>  
<td>

Data is initially collected on a particular research computer within the
research group. Useful data is then copied to a local server according to
existing research group policies, and/or copied to the consortium’s main
server located in the RaM lab of the University of Twente, Enschede, The
Netherlands. Only authorized persons will have access to the RAM main server.
After copying, the data on the local computer will be deleted.

</td>  
<td>

Research groups follow existing policies for data backup.

The consortium’s main server will have three copies: the server itself
(original), an on-site backup drive (back-upped weekly) and an off-line, off-
site drive (back-upped monthly). All drives have a size in the order of one
TB, with the intention that it can store all data (original and processed)
within the project. If at some point in the project the allocated storage size
appears to be insufficient, then the storage size will be increased.

In present times, threats not only come from possible hardware damage and
theft which can destroy local data only, but also from crypto locker
infections (ransomware) which can encrypt all data accessible by the infected
computer’s filesystem, including network shares and cloud storage. Therefore,
at least one backup drive will be logically disconnected from the server.

</td> </tr>  
<tr>  
<td>

**Raw data at hospital**

</td>  
<td>

After anonymization, the data will be transferred to researchers. One option
is via secured USB devices as this is the default way of sharing DICOM.

</td>  
<td>

When raw medical data (e.g. DICOM data) is copied from secured USB device to a
researcher’s computer (and possibly network drive or cloud), the original
secured USB device serves as back-up.

When the raw data are stored in the network drive and/or cloud, backup
procedures can follow the same one as for raw data at research group (see
above).

</td> </tr>  
<tr>  
<td>

**Processed data**

</td>  
<td>

During development, data is processed at researcher’s computers and initially
also stored there. Useful datasets (collection of processed MRI, ultrasound
coupled with probe position, segmentation data, elastography, 3d volume model,
simulation data of the same phantom) are put on the group’s project server
(network drive etc.) and later moved to the consortium’s main server. As the
data is no longer needed on the researchers computer, the data will be
deleted.

</td>  
<td>

Processed datasets belong to the partner that generated/processed it; data
which is relevant for other partners are shared with them via the consortium’s
server.

At end of the project, each partner itself decides which part(s) of their data
is selected for publication under Open Access. These parts will be collected,
filtered, documented and uploaded to a permanent storage location that is
accessible for everyone.

</td> </tr>  
<tr>  
<td>

**“MURAB non-research data”: files that are not research data, such as design
files, organizational files etc.**

</td>  
<td>

Design files and software source code are not research data and thus
technically outside the scope of this document. It is included here only
because these files need back-up and version management as well.

Design files and source code are developed on researcher’s computers. When
multiple people are working on same software, then a protocol like SVN, Git,
Mercurial, effectively used by software

</td>  
<td>

Organizational files that are relevant for all partners, are also put on the
consortium’s main server.

</td> </tr>  
<tr>  
<td>

</td>  
<td>

like gitlab (self-hosted) will be used, operating from a group’s server.
Otherwise, models and code are shared over the network drive, and versioning
is managed by file naming conventions.

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Informed consents (include names and signatures of informed participants).**

</td>  
<td>

Patient related research will include IRB approval and informed consent. We
will use existing procedures at hospitals and its data stays at the hospitals.

Consent forms will be kept in a locked cabinet in the office of the project
manager who is the only person with a key to the cabinet.

Privacy-sensitive data will never leave the hospital’s boundary.

</td>  
<td>

Hospitals already have existing infrastructure (and associated policies) for
backup and storage.

</td> </tr> </table>

##  Consortium’s main server

The University of Twente will provide the consortium’s main server on which
master copies of all (anonymized) data can be stored and accessed by all
partners. For the permanent server solution two options were considered:

  1. Use of a virtual server provided by ICTS, a service by the University of Twente. This service includes scalable storage size and backups (both on-site and off-site). 

  

  2. Use a physical computer, server or network-attached storage (NAS) located in the Robotics and Mechatronics (RaM) lab. The management and maintenance part will be performed by technicians. 

  

  

Option b will be chosen and further implemented by the summer of 2016\.

The services (data storage and project management) are protected by
authentication via Lightweight Directory Access Protocol (LDAP). All
researchers within the consortium will receive credentials to make use of the
server functionality. No people outside the consortium will gain access to
research data on the server.

##  Length of time regarding use of data, storage and destruction of data

The data (anonymised) will be kept indefinitely, but the linking data will be
destroyed after completion of the research. The consent forms will be
destroyed after ten years.

#  Data Documentation

##  Description documents

In each dataset, a master document describes all the data contained in that
dataset. It describes the overall folder hierarchy, and links to other
documents and spreadsheets that describe the different parts of the data.
Publication restrictions are described here as well (open access or
protected).

For phantom and anonymized patient examinations, data is grouped into
sessions. A session is a sequence of examinations and procedures on the same
phantom or patient. The session log at least contains the date, investigator,
types of examinations, analytical and procedural information and all links to
the associated examination and/or processed data, such as folder locations
containing the examination files. An examination can be a MRI scan, an
ultrasound scanning sequence, a partial or full MURAB procedure with all
associated data, or an entirely different research associated with the
project. Processed data could be a 3d elastography model, pre-operative path
plan, in-biopsy deformation, postbiopsy path analysis etc. All session logs
are documented; either into a single document or spreadsheet, or distributed
over a collection of documents/spreadsheets linked by the master document.

Each type of examination or processed data is also documented separately in
general. For MRI data, this documentation at least states that the format is
DICOM and that it can be viewed in most DICOM viewers such as 3D Slicer or
3DimViewer. For ultrasound, the document exactly describes the data format(s)
and how it can be accessed. Likewise, data types related to other examinations
and MURAB procedure stages are documented in a similar fashion. For primary
researchers (researchers within the consortium), all data is documented and
made available by default. For secondary researchers, the open-access part of
the data and its documentation (specific for the open-access dataset) is
uploaded to a databank.

##  Folder policy and data linking

When data is stored on the network drive / cloud storage, there is a general
folder policy that has to be adhered to whenever possible:

  * In every folder there is a readme.txt file describing the contents of the folder; in case of research data it describes which kind of data is found (e.g. MRI, ultrasound, camera), who created the data, on which date etc. 

  

  * Folders and subfolders must be organized following one of these logical structures: 

    * **Option 1)** Different types of data of the same session (e.g. MRI and ultrasound data from the same breast phantom, and its derived data) are put in different subfolders of the same folder. 

  

    * **Option 2)** Put all MRI data in one folder hierarchy, all ultrasound data in another folder hierarchy, and other type of data in yet another hierarchy. In this case, a spreadsheet will be used to link the data together. The spreadsheets contain the relative folder locations for the different types of data belonging to the same patient. 

  

  

Which is the best option is yet to be seen; in any case the data should be
logically organized so that datasets of the same type (or the same case) can
be easily found in the folder hierarchy. Therefore, we have to work consistent
and keep all data in the same hierarchy, avoiding fragmentation.

##  File naming convention

Default naming convention of files (folders): YYYYMMDD_Name_v1.0_AuthorI.ext.
If files in a folder do not follow this convention, then at least one parent
folder in the hierarchy should do. For example, a folder with DICOM data
consists of an IMAGES directory with files named like IM1234. These names are
part of the DICOM specification and the names cannot be changed, so the parent
folder of the IMAGES directory should follow the default naming convention.

##  Identifiers

Each dataset will be given a unique and persistent identifier. These will be
defined when the dataset itself is being generated and/or published. When a
dataset is uploaded to a databank such as 3TU.Datacentrum, then a DOI is
automatically assigned to the dataset.

#  Data Access

Legal issues considering IP (intellectual property) of anything generated
within the project, including research data, will be covered in the Grant
Agreement, supplemented by the Consortium Agreement. In particular, research
data is owned by the partner(s) that generated it.

##  Access right for the consortium members

During the project, all consortium members have the rights to use the data
generated by any partner in the project, if this is needed for executing the
tasks as defined in the Grant Agreement. The primary method for accessing the
data is by using the consortium server. All data on the server is made
available to all partners by default, in principle it is never needed to grant
access data to specific partners only. All medical data on that server is
anonymized, so a basic level of security such as single-factor authentication,
suffices.

**5.2 Access rights for external users**

During the project, external users have no access to the research data.

#  Data Sharing and Reuse

MURAB project participate in the Horizon 2020 Pilot on Open Research Data and,
therefore, is committed to make public the research data that does not belong
to IP. MURAB will define all suitable measures to enable third parties to
access, mine, exploit, reproduce, and disseminate (free of charge for any
user) its research data.

##  Research data being used in scientific publications

After publication of a paper, the original data files are made available by
using open-access. Other researchers may want to validate the results from the
project’s papers, requiring access to the data after publication of the paper.

##  Non-IP data after end of project

At end of the project, the MURAB research data that is not part of IP, will
also be made open-access. The subset of the data which is non-IP will be
discussed in a consortium meeting around July 2019 (six months before end of
the project). Also, the embargo period will be decided here.

Several types of data might be useful for other researchers that also work on
registration of different imaging modalities where deformable tissue is
involved. In MURAB’s case, the researchers record raw MRI and tracked
ultrasound data for position of the robotic arm on which other groups can try
their algorithms for registration and 3d volume reconstruction. This processed
data (reconstructed 3d volume with elastography information, needle insertion
path planning etc.) might be used as a reference point to quantitatively
evaluate the performance of their algorithms. Raw data using one specific
modality (e.g. MRI) from patients could also be useful for researchers working
on a different kind of study who need MRI scans of different patients.

MURAB will publish datasets in public-available databases alongside with
publications and at the end of the project, for example in 3TU.Datacentrum or
in a subject-based/thematic repository, and coupled with a Digital Object
Identifier. A Creative Commons Licence will be applied to the MURAB project
research data. The MURAB website will probably also refer to these datasets.

##  IP data after end of project

IP data stays by its respective owner(s). If a partner wants to commercialize
project results and needs IP of other partners, they have to gain access to
these rights taking normal market conditions into account.

#  Data Preservation and Archiving

After the end of the project, linkage information connecting patient names to
codes shall be destroyed.

Part of the data is placed in an Open Access dataset. Only data that is deemed
useful for other researchers and does not belong to intellectual property of
any partner of the consortium, is included in this dataset. Data that contain
no scientific value (testing data, incomplete cases, failed experiments etc.)
or data containing IP (especially models and code) are omitted from the
dataset. This way, high research data quality of the Open Access dataset is
ensured, without disclosing IP.

After the end of the project, the University of Twente is no longer obliged to
maintain the consortium server. All partners can make a copy of all data for
themselves, taking IP in mind. What will happen with the data on the
consortium server, will be discussed near the end of the project. If the RaM
group decides to keep the server (e.g. if there is a continuation of the
project), the server with all data can be transferred to the RaM group, taking
IP rights into account. Another option is to store all data for longterm,
protected storage in the 3TU.Datacentrum or other digital repository.

#  MURABproject.eu