Title

Imaging

Profile metadata

2023-08-11 Versie 0.0.1

Release-information

The scope of this profile now concerns radiology/radiotherapy (DICOM):

• (Radiological) images from care in PACS

• Images and derivatives in a research setting in PACS, research PACS or regular data storage

Not considered for this version are: nuclear images, pathological images, ophthalmology, stereolithography, video images, microscopy, etc.

Roles and actors

The article roles describes the generic roles within the Health-RI ecosystem. Within Imaging there are specific specifications for the following roles.

Data producer:

• Principal investigator (In case of Research data, with METC approval) 

• Data responsible person: Department Head or Research Data Management (in case of retrospective use of healthcare data) 

• Maybe this should be data controller, person responsible for data production. 

Data preparator:

• Principal Investigator (e.g. PhD students, postdoc, research software engineer) 

• Data and domain specialist (e.g. Radiologists, Fellows, technicians/laboranten) 

• Data manager (quality control, pseudonymisation, e.g. Imaging Trial Office) 

 Data-provider:

• Data manager (e.g. Imaging Trial Office, Consortium data manager, but is not always there) 

• Principal Investigator (e.g. PhD students, posdoc, research software engineer) 

Local review committee data providing may include (dependent on the organisation):

• Medical Ethics Committee: first approval for data collection/set-up study, only if in research setting generated data. 

• Data Protection Officer 

• Data responsible person: Department Head or Research Data Management (Local DCC, at Amsterdam UMC). 

• Additional people in case of consortium 

Data governance committee:

• the Health-RI Imaging working group for national imaging data

Ways of data exchange

Various delivery processes are possible for imaging data. The options are:

1. Give someone access to persistent data platform for downloading (Pull option / central)

2. Give federated data node (PHT local station) access to local persistent data platform (pull option / federated)

3. Enter data into DRE (or e.g. central XNAT) (push option / central)

4. Send data to federated node (push option / federated)

5. Send data to the recipient via a data exchange platform (e.g. WeTransfer, SURFdrive, SharePoint).

Implementation

Within imaging, there is a close link at the persistent data layer between the imaging data and the tooling to view and analyze the imaging data and annotate it.

Imaging data research platforms include:

• local XNAT (alleen DICOM)

• staging area of grand-challenge (AWS)

• local Flywheel (commerciele versie van XNAT)

• Conquest

• Orthanc

• network drive with a certain structure in combination with data manager and set of scripts/guidelines to enforce that structure

• any other "research-PACS system

• Hyland VNA (Vendor Neutral Archive)

• Philips system (e/MTIC)

• Microsoft Azure Datalake

• Google Health api

• AWS Health lake

See also Storyline: Making imaging data available

Pseudonymisation

When transferred to the persistent data layer, the DICOM files are pseudonymised: directly identifiable fields from the DICOM header are removed and replaced by another ID.