Skip to main content

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

From: The generic Informed Consent Service gICS®: implementation and benefits of a modular consent software tool to master the challenge of electronic consent management in research

No. Requirement and/or use case gICS solution
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