Table 2 List of requirements for a comprehensive informed consent management (see Table 1) and respective solutions using gICS

1

Support of a general consent form for a research project

By design gICS facilitates to create general as well as project-specific templates for informed consents [25]

2

Support of individual participant consents

To address individual requirements of cohorts or groups of participants, the structure of each template can easily be adopted to the target groups’ needs using gICS

3

Clarity and transparency regarding each consent status to support Use and Access processes in compliance with data protection regulations

gICS supports depicting the participants’ will for each application scenario, such as Use and Access, in currently nine values: Accepted, Declined, Unknown, Not asked, Not chosen, Withdrawn, Invalidated, Refused and Expired [26]

4

Editing and updating a consent

The participant is enabled to change his/her will at any time. A given consent can be updated as well as withdrawn without any restrictions using gICS. For a precise chronological documentation every change results in a new “latest” and versioned consent easily manageable with gICS [25]

5

Support of consent exclusions

gICS supports the “opt-in” approach, which is the EU-GDPR default. To exclude specific purposes of data usage, the project consent has to contain a respective consent module, which can be accepted or declined by the participant. [25]

6

Possibility to define any number of (external) properties

To achieve a maximum of flexibility, the gICS data model allows to define gICS-specific properties (e. g. mandatory scans, scan size limits, permanent withdrawals, version and date weighting) and application-specific (external) properties (e. g. VALIDITY_PERIOD = p1y30d) for policies, modules and templates. [25, 27]

7

Possibility to define free text fields

Each consent template in gICS can be enhanced with free text fields of the types DATE, BOOLEAN, STRING, INTEGER or DOUBLE, e. g. to additionally document the name of a treatment facility. [25]

8

Possibility to withdraw consent (fully or partially)

The modular structure of consents within gICS facilitates partial and full withdrawals, e. g. as successfully applied in the German National Cohort. [25]

9

Support of consent versioning

Each policy, module and template of a consent references a specific version in gICS to ensure reproducibility. [25]

10

Possibility to freely configure automatable queries for consent status

gICS facilitates the functionality to request consent status (policy-based) via interface including further possible configurations as “ignoreVersionNumber” or unknownStateIsConsideredAsDecline [27, 28]

11

Possibility to define policies and combine them into modules to support fine-granular depiction of the participant’s expressed consent

gICS uses policies and modules as fine-granular as needed for a comprehensive consent representation [15].

12

Possibility to define mandatory policies/modules

Each consent module references assigned consent policies in gICS. For each consent template within gICS mandatory consent modules can easily be specified [25]

13

Possibility of automated search or query of individual, consented consent form, policies, modules or specific identifiers, e. g. case number

Using automated searches or queries of consent, policies, modules or specific identifiers already provided by gICS or manually created by the researcher, e. g. by using the search-function of the web frontend [25]

14

Support of exporting consented cases, e. g. by providing a list of participants’ pseudonyms with valid consents

gICS offers more than 50 comfort functionalities via a web service-based interface (SOAP) to manage and query consents and respective information. A complete list of functions and required parameters is provided in the online specification [25, 28]

15

Integration of paper-based workflows, e. g. attaching documents to a participant’s digital consent

Digitising and managing consents in gICS includes the possibility to upload one or more files (PDF-format, jpg), e. g. a scanned document of the participant’s paper-based consent, to the digital consent [25]

16

Management of domains (e. g. projects, study countries or sites)

Possibility to use specific domains in gICS and the gICS web frontend to manage those domains [25]

17

Intuitive usage and support of use cases

The up-to-date web-frontend of gICS supports the most common application scenarios while additional comfort functionalities, provided by the web-based interface, facilitate system integration purposes

18

Possibility to define the time of validity of a consent

Within gICS a consent’s time period of validity can be defined either by a fixed date, e. g. end of the research project, or by a dynamic date, e. g. 18th birthday of a study participant. This can be defined for domains, e.g. a study, specific consent templates, or modules