Background
Research becomes more and more complex, increasingly involving (inter-)national partners collecting, transferring, processing and storing growing amounts of data from different sources. Consequently, complying with relevant (legal and ethical) regulations is often a challenge. The requirement that each participant in a research project provides an “informed consent” (IC) is widely seen as a cornerstone of the ethical acceptability of medical research involving human subjects.
The concept of informed consent is often referred to as the ethical and legal answer of the Nuremberg Court [
1] to the horrific experiments of Nazi doctors with hospital patients or inmates of the concentration camps. However, this concept has several origins.
In the U.S., the Tuskegee Syphilis Study was conducted between 1932 and 1972. In this study, participants received false information about the nature and the duration of the research, which included withholding available treatment from affected patients to observe the “natural course of the disease” – with numerous severe consequences for their own and their relatives’ lives [
2,
3]. The example of this study demonstrates that massive IC-related shortcomings endangering the health of the participants and violating their basic human rights occurred not only in interventional research but also in pure observational epidemiological research. The immense mistreatment of participants within the Tuskegee study led in great parts to the Belmont Report – one of the most influential research ethics codices until today [
4].
Both lines, the extraordinary abuse of people by Nazi doctors as well as the less known mistreatment of study participants within mainstream medical science, triggered a development after the end of the 2nd World War that resulted in the publication of several research ethics codices, defining and protecting participants’ rights in the sphere of human subject research. Besides the well-known Declaration of Helsinki that appeared in its first version in 1964 [
5] numerous codices and laws today regulate the interaction and treatment of people participating in medical research. All pertinent regulations emphasise the IC as an inevitable element of the process of research with human subjects. These days the focus on direct physical and psychological violations of study participants and their relatives extends to harm resulting from the potential misuse of participants’ data. In the era of international multi-site studies and “big data medicine” these aspects of IC become more and more relevant. Today, handling patient data for research needs to be compliant with legal requirements stated by the EU General Data Protection Regulation (GDPR) as well as national legislation, e.g. the German Data Protection Act (German: Bundesdatenschutzgesetz, BDSG) and the Data Protection Act of the respective federal state (German: Landesdatenschutzgesetze, LDSG).
According to MITRE [
6] “[…] consent management is a system, process, or set of policies that enables […]” participants to decide what healthcare providers and researchers are allowed to do with their health information, and to extend this to all kinds of specific personal information. Patient’s health information, i.e. medical data, are classified as personal data, which are considered particularly sensitive, and, thus, can only be processed with a patient’s informed consent [
7]. Deviating from MITRE [
6], this paper uses the term “informed consent” for a participant’s written decision defining the use of personal health information for research purposes only (as opposed to use for treatment, reimbursement or other purposes).
Informed consent means that individuals are not only informed about the contents of a study but also understand the information given. Thus, the consent should be discussed with the eligible participant and only signed
after this discussion but
before the data collection [
8].
Usually, the consent of an eligible study participant is captured on a paper-based form that is signed by the participant. Such a paper-based approach usually does not include structured information and is not machine-readable. An electronic consent management facilitates the capturing of consent in a digital format—either digitising a paper-based consent (including scans of consents) or directly capturing the consent digitally via electronic consent mechanisms. Consequently, the participant’s permissions for usage together with his/her choice of restrictions including partial and complete withdrawals can be handled based on automated algorithms by an Informed Consent Management System [
6]. Electronic consent management has major advantages compared to conventional manual handling, which leads to repeated searching for a participant’s specific written statement, uncontrolled storage of paper-based forms, and availability at only one location. Additionally to facilitating processes—especially regarding modular consents—and reducing time demands, electronic consent management has logistic advantages that can be substantial. For example, the German National Cohort (NAKO, [
9]) stores more than 307,000 consents (as of October 2019), which corresponds to paper-based forms in excess of no less than 10 tons.
Despite these advantages, electronic consent mechanisms were still an unsolved issue in 2007 [
8], and even in 2014, MITRE [
6] stated that “[…] electronic consent management is not yet common practice […]” and it was still common to collect consents solely on a paper form.
A literature search regarding “Informed Consent Management” showed that existing (open-source) software tools for consent management differ in their use cases and application context. For example, the consent wizard of the Technology, Methods, and Infrastructure for Networked Medical Research e. V. (TMF) [
10] supports its users in the creation of consent documents, but does not offer help in managing, versioning, modularising or querying consents and withdrawals digitally. The Consent Management Suite (COMS) [
11] facilitates the creation and administration of consent documents in the context of medical treatment. However, it also does not support versioning, modularising or querying consents and withdrawals digitally. The School of IT and Computer Science at the University of Wollongong, Australia, developed the eMedical Book Consent providing a “General Consent with specific Denials” or a “General Denial with specific consents” prototypes, respectively, for electronic health records (EHR) [
8]. In this case, the consent is a security profile, granting or denying access to, amongst others, the patient’s medical history, examination, consultation and health assessment [
8]. It may also be useful for research, but the software solution seems not to be accessible to other research facilities. Additionally, commercial products exist [
12,
13]. However, those tools are too expensive for most research projects with limited resources.
Consequently, there is a need for computer-assisted IC processes with sufficient flexibility of applications in a large variety of settings and use cases. The University Medicine Greifswald developed a scalable generic– thus, portable and adaptable - approach to implement a generic Informed Consent Service (gICS) to facilitate consent management for all possible study types and settings, with a focus on epidemiological research studies and registries. gICS was published as free-of-charge and open-source software within the MOSAIC project [
14] (funded by the German Research Foundation (
HO 1937/2-
1)).
This paper discusses the organisational development and technical implementation of the software solution gICS for the creation, management and modularisation of informed consents as well as its support of policy-specific automated queries and withdrawals. Additionally, it evaluates the benefits for research projects using this modular consent software tool.
Discussion
Most tools for research are in-house or specifically tailored solutions with the disadvantages of varying technical staff or the end of tool support after a project’s finalisation. To ensure reusability in new projects as well as a widespread provision of a consent management tool for the scientific community, gICS is provided as open-source, free of charge software tool. Due to Docker, gICS is easy to install and supports research projects with limited resources regarding IT experts and finances. Additionally, gICS is suited for research projects with short as well as long project durations and has no practical limits regarding number of consents or consent template versions. Its generic approach and web-based client application allows necessary customisation—even in small and researcher-driven studies and registries with only a minimum of IT resources.
gICS supports all requirements and use cases regarding IC management as listed in Table
2. Requirements regarding IC structure and granularity as stated by the TMF [
16] and GDPR [
7] can be implemented and utilised using gICS. However, using gICS does not automatically guarantee a high degree of legal compliance, since the consent’s content is responsible for securing participants’ rights. gICS only supports the management of consent documents as well as permissions and prohibitions (regarding policies) stated by the participant. Using an IC is the responsibility of data management units and study sites [
25]. The content of the informed consent and the resulting policies and modules have to be developed by the researcher—support, guidelines and requirements are provided in the literature [
29] or at websites from institutions working in data protection. For example, text snippets and content templates for developing consent documents to use for research and to guarantee a high degree of legal compliance (in Germany) can be found at TMF [
10]. gICS cannot substitute for an examination of the consent documents by the responsible ethics committee.
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 |
The status variables included in gICS are not restricted to the array of values used in the existing projects. Rather, they include values, which can be further adapted for future research projects. Nevertheless, certain preferences in the usage of those values can already be identified leading to the question of practical implications of the not-yet-used values. This will be evaluated with an interdisciplinary team and based on more research projects in the future. In any case, using a fine-granular consent with different consent status values, which can be directly exchanged between systems, allows the automated processing of granting or denying access to specific health-related information. Thus, gICS may also be suitable for the integration into an EHR system. However, gICS as an IC management tool does not provide authentication mechanisms. Such processes as well as implementations to handle and monitor authorisations have to be defined outside of the gICS-application, e. g. using a dispatcher.
According to MITRE [
6], the future is to collect consents digitally. Until today, however, it is required to hand out a paper copy of the patient information as well as the signed consent form to study participants and patients in Germany. Consequently, this leads to a still paper-based process: Usually, when using SignPads to digitally capture consents the completed e-consent is printed out as a copy for the participant. However, a future gICS-feature could also include providing the consent electronically to the participant, e.g. via e-mail.
Conclusions
The introduced approach of the generic Informed Consent Service gICS supports the automated processing of ICs, and use cases of a broad range of research projects to collect and manage ICs in compliance with their workflows as well as legal and ethical requirements.
gICS is under on-going further development and integration in work processes. For example, within the MAGIC-project (2016–2018) funded by the German Research Foundation (DFG) (grant number HO 1937/5-1) an FHIR-based exchange format was proposed [
25]. Additionally, it will be used and further enhanced in the complex multi-site network MIRACUM (Medical Informatics in Research and Care in University Medicine; grant number: FKZ 01ZZ1801M) [
30] leading most likely to further use cases.
A tool like gICS to simplify and support a sustainable IC management is a major key to successful study implementation and trust building with participants and the public. Therefore, interested researchers are invited to use gICS [
21] and provide feedback for further improvements.
Publisher's Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.