Skip to main content
Download PDF
  • Research article
  • Open access
  • Published:

A FHIR has been lit on gICS: facilitating the standardised exchange of informed consent in a large network of university medicine

BMC Medical Informatics and Decision Making volume 22, Article number: 335 (2022) Cite this article

Abstract

Background

The Federal Ministry of Education and Research of Germany (BMBF) funds a network of university medicines (NUM) to support COVID-19 and pandemic research at national level. The “COVID-19 Data Exchange Platform” (CODEX) as part of NUM establishes a harmonised infrastructure that supports research use of COVID-19 datasets. The broad consent (BC) of the Medical Informatics Initiative (MII) is agreed by all German federal states and forms the legal base for data processing. All 34 participating university hospitals (NUM sites) work upon a harmonised infrastructural as well as legal basis for their data protection-compliant collection and transfer of their research dataset to the central CODEX platform. Each NUM site ensures that the exchanged consent information conforms to the already-balloted HL7 FHIR consent profiles and the interoperability concept of the MII Task Force “Consent Implementation” (TFCI). The Independent Trusted Third-Party (TTP) of the University Medicine Greifswald supports data protection-compliant data processing and provides the consent management solutions gICS.

Methods

Based on a stakeholder dialogue a required set of FHIR-functionalities was identified and technically specified supported by official FHIR experts. Next, a “TTP-FHIR Gateway” for the HL7 FHIR-compliant exchange of consent information using gICS was implemented. A last step included external integration tests and the development of a pre-configured consent template for the BC for the NUM sites.

Results

A FHIR-compliant gICS-release and a corresponding consent template for the BC were provided to all NUM sites in June 2021. All FHIR functionalities comply with the already-balloted FHIR consent profiles of the HL7 Working Group Consent Management. The consent template simplifies the technical BC rollout and the corresponding implementation of the TFCI interoperability concept at the NUM sites.

Conclusions

This article shows that a HL7 FHIR-compliant and interoperable nationwide exchange of consent information could be built using of the consent management software gICS and the provided TTP-FHIR Gateway. The initial functional scope of the solution covers the requirements identified in the NUM-CODEX setting. The semantic correctness of these functionalities was validated by project-partners from the Ludwig-Maximilian University in Munich. The production rollout of the solution package to all NUM sites has started successfully.

Peer Review reports

Background

A national network of university medicine

The Federal Ministry of Education and Research of Germany (BMBF) is funding a national network of university medicine (NUM) to support COVID-19 and pandemic research at national level. Within the NUM project “COVID-19 Data Exchange Platform” (CODEX), as one of several funded projects of NUM, a nationwide standardised infrastructure is to be established that supports the storage and provision of COVID-19 research datasets in a data protection-compliant manner [1, 2].

For this purpose, the structured COVID-19 data of the participating 34 university hospitals (NUM sites), which include clinical data, image data and data on biospecimens [3], are to be pseudonymously transferred in the form of the German Corona Consensus data set (GECCO83) [4] in the central platform CODEX. The assessment of patient related data, the transfer to a comprehensive, standardised data repository, and the use & access procedure, that will allow researchers to analyse the data to answer urgent scientific questions, are all based on an individual informed consent.

The infrastructure required for multicentre data exchange must meet the requirements of research ethics and the EU General Data Protection Regulation (GDPR). The planned processing of a patient's health data at the NUM site and the standardised transfer to the central platform CODEX for research purposes requires, according to the GDPR Art. 6 (1) lit. a) [5], the consent of the patient.

In a complex interaction of centralised and decentralised infrastructure components, the transfer of appropriately consented health data at the NUM sites to the central platform is only indirect. Each individual site has a data integration centre (DIC) and a local Trusted Third Party (TTP) including a local consent management. The NUM sites ensure that only consented data is transferred to the central research repository CODEX. Central infrastructure components, such as the federated Trusted Third Party (fTTP), ensure, that patients can be uniquely identified across sites based on a privacy preserving record linkage (PPRL) [6]. Uniformly generated pseudonyms are provided by the fTTP. The GECCO Transfer Hub (GTH) transfers the pseudonymised research data to the central platform CODEX using the HiGHmed Data Sharing Framework (DSF) [7]. The exchange of person-identifying information (PII), health data and consent data are carried out in NUM by means of the Health Level 7® (HL7) standard Fast Healthcare Interoperable Resources® (FHIR).

A broad consent promotes broad research

In the Medical Informatics Initiative (MII) the BMBF funded the four consortia, MIRACUM [8], HiGHmed [9], SMITH [10] and DIFUTURE [11]. The aim of the MII, which started before NUM, is, among others, “to improve medical research and patient care with innovative data architectures and software solutions” [12]. This project is primarily based on decentralised infrastructures and is not limited to COVID-19 or pandemic research, but shall support a very broad approach of medical research based on patient data from diagnostic and therapeutic clinical routine in all University Hospitals in Germany, and their cooperation partners.

In order to solve MII-wide challenges in a uniform manner, a number of corresponding working groups and task forces were set up. Particularly, the working group consent (WG Consent) has designed a uniform and modular consent document: the MII Broad Consent (version 1.6d) [13]. Moreover, the WG Consent has successfully coordinated this broad consent, which was approved by all the data protection authorities at both all federated states and the national level in Germany. It shall “be used over all sites in the four consortia” [12].

In close cooperation between WG Consent and the Technology, Methods, and Infrastructure for Networked Medical Research e.V. (TMF), the already approved MII Broad Consent (MII BC) [14] was extended for NUM by a NUM-specific consent module (version 1.6f) [15]. This supplementary module (called Z-module) grants patients the opportunity to decide on their own responsibility (1) whether their data may be transmitted to the central platform CODEX for the purpose of COVID-19 and pandemic research, in order to then be used for research in conformity with the GDPR, and (2) may even be transferred to countries in which the European Commission did not explicitly confirm a suitable level of data protection, yet (“unsecure third countries” [16]).

Ideally, the NUM-specific version of the MII Broad Consent (v.1.6f) is to be used at all NUM sites as a uniform basis for the data protection-compliant collection and transfer of the GECCO83 data set to the central platform CODEX.

A harmonised representation of the patient’s consent for technical interoperability

As each site of the four MII consortia is free to choose the technical implementation for managing consent information, such as Integrating the Healthcare Enterprise (IHE) Basic Patient Privacy Consents (BPPC) or FHIR consent resources [17], the MII Task Force Consent Implementation (TFCI) has successfully faced the challenge of defining a technically interoperable solution [18]. The TFCI utilised globally unique object identifiers (OID) to develop a common representation of the MII Broad Consent [18].

This approach was extended with a concrete set of semantic statements for each consent module as selected by the patient (enforceable consent policies). Corresponding representations of questions, answers, modules and assigned policies of the MII Broad Consent were modelled in ART-DÉCOR [19, 20] after intensive coordination with WG Consent and TMF.

Since every NUM site is also a MII site, corresponding additions for the NUM-specific extension of the MII Broad Consent (version 1.6f) have already been considered. Despite considerable complexity, TFCI has paved the way for the technically independent exchange of semantic consent information in MII and NUM.

Each NUM site is responsible for the individual implementation of this interoperable but complex approach. This also includes ensuring that the content of the exchanged consent information is always semantically correct in order to prevent possible data protection violations (e.g. data transmissions to the central platform CODEX in the absence of a valid consent).

A reliable consent management is essential to ensure patient’s rights

The Independent Trusted Third-Party (TTP) of the University Medicine Greifswald has successfully supported the data protection-compliance of research projects since 2014 (e.g. NAKO Health Study, German Centre for Cardiovascular Research) [21]. The open source solutions gICS® (generic Informed Consent Service), gPAS® (generic Pseudonymisation Administration Service) and E-PIX® (Enterprise Master Person Index) form the basis for the implementation of the informational separation of powers [22]. These TTP tools are part of the MIRACOLIX Toolbox 2.0 [23] of the MII consortium MIRACUM. The correct consideration and implementation of the patient's rights, in particular the handling of consents and the implementation of patient withdrawals, require a reliable consent management [12].

University Medicine Greifswald has already successfully implemented a completely digitally MII broad consent in mid of 2020 [24]. As part of the NUM-CODEX project, the University Medicine Greifswald supports the NUM sites to establish necessary local Trusted Third Parties and corresponding consent processes by providing the necessary software solution gICS for digital consent management.

Each NUM site decides individually whether to apply gICS for local consent management. Also, efforts required to integrate gICS into individual processes and infrastructures remain with the site. This typically includes not only technical aspects (e.g. network zones, authentication, various local IT-security measures), but also human resources for sufficient information of the patient, retrieval and documentation of consent, as well as for quality control of consent information.

gICS supports digital- and paper-based consent processes and follows the principles of “privacy by design” [12]. Based on consent policies and consent modules gICS allows to automatically determine and query the detailed consent status for each patient at any time [17]. The web-based functionalities of gICS have so far been provided to users exclusively via SOAP interface [25]. In the NUM-CODEX project, however, the exchange of consent information is intended solely in HL7 FHIR format. Due to a lack of uniform specification, this has not yet been satisfactorily supported by any other software solution [17].

A standardised specification for FHIR consent

In order to be able to implement the clear objective in the NUM-CODEX project for cross-site data exchange via FHIR in the area of consents, current developments in the FHIR community must be considered. The HL7working group on consent management (WGCM), with significant participation from University Medicine Greifswald, has fundamentally renovated the handling of FHIR consent resources in collaboration with representatives from all four MII consortia. With regard to national characteristics in Germany, required profiles, vocabularies and extensions for the exchange of modular consent templates and contents were specified [26], considering applicable standards such as IHE BPPC and IHE APPC [27], and numerous examples were made available in the form of a uniform implementation guide [28]. This specification is publicly available and the balloting process started in April 2021, in order to introduce these new profiles as part of the official national HL7 FHIR standard.

The examples provided by the WGCM consider the OID-based preliminary work of the TFCI. The challenge of the syntactically and semantically correct implementation of these complex FHIR consent profiles, however, still exists and requires both extensive practical experience in the field of consent management and a comprehensive understanding of the designed FHIR consent concepts.

Objectives

This article describes the necessary steps for the conception and implementation of a standardised solution for the FHIR-compliant provision of consent information using gICS, which can support both existing user projects and future users in the implementation of FHIR-oriented infrastructures and processes. The following conditions apply:

  1. 1.

    at least the FHIR-Consent Profiles as specified by the national HL7 Working Group on Consent Management (WGCM) [26] should be supported,

  2. 2.

    additional requirements resulting from the specific setting of NUM should be considered (such as the implementation situation at the sites, planned cross-site processes)

  3. 3.

    and in order to simplify the application at the sites of MII and NUM, the interoperability concept of the MII Task Force “Consent Implementation” (TFCI) based on operationalised consent policies [20] should be facilitated.

Methods

Due to the very limited time resources in the NUM-CODEX project, the development of a solution and the coordination with the involved stakeholders, was carried out in parallel. This required intensive communication between all those involved parties and an iterative approach adapted to the particular situation.

Extending the modular TTP approach

Whereas the separate TTP tools have been used for each area of responsibility of current Trusted Third-Party implementations [21], a distinct module should be applied for consistent FHIR format conversions. This particular “Trusted Third-Party FHIR Gateway” (TTP-FHIR Gateway) should serve as an intermediary between external FHIR-specific infrastructure components and existing TTP tools like gICS. This approach has two advantages:

  1. 1.

    As a stand-alone software component, an integration of the TTP-FHIR Gateway into existing infrastructures can be achieved with little effort: existing application servers that already provide TTP services based on the TTP tools are simply supplemented with another deployment.

  2. 2.

    An implementation in different application scenarios is conceptually possible by an appropriately configurable TTP-FHIR Gateway and without additional efforts for (a) sites which use gICS only as well as (b) sites which use a combination of TTP tools like gICS, gPAS, E-PIX or TTP dispatcher [21].

Identifying a basic set of FHIR-functionalities based on stakeholder dialogue

The TTP-FHIR Gateway for gICS shall be used at the individual NUM sites and thus support the planned data flows from 34 NUM sites via the GECCO Transfer Hub (GTH) to the central platform CODEX. For this purpose, options for simplification of connecting the sites to the NUM infrastructure were discussed with partners from the University Medicine Erlangen, including queries to the local consent management via TTP-FHIR Gateway.

The partner site Heilbronn is responsible for the implementation of the GTH using the DSF [7]. The FHIR consent resources delivered by the TTP-FHIR Gateway were consolidated with the partner Heilbronn, as the GTH ensures that only correctly consented GECCO data sets may be transmitted to the central platform. This validation is currently planned for implementation based on the TFCI concept for interoperability.

In order to support these planned processes correctly, four essential functionalities for the TTP-FHIR Gateway to handle FHIR consents resources were identified from this stakeholder dialogue:

  1. 1.

    Retrieval of all consents of a specific research project (consent domain)

  2. 2.

    Retrieval of the most current consent of a specific patient (regarding a specified consent template)

  3. 3.

    Patient-specific check of the consent status (e.g. “Is the scientific use of the patient's medical data for the intended purpose legally permissible at the current time?”)

  4. 4.

    Retrieval of a complete set of documented consent policies signed by a patient classified by “deny” or “permit” [29]

According to the interface specification, gICS 2.12.0 covers these functionalities via the freely available and documented SOAP interface [30]. The FHIR-compliant specification of corresponding FHIR functionalities, including necessary request and response parameters, had to be added.

Ensuring a FHIR-compliant design

In order to ensure the syntactic correctness of FHIR-related contents and functionalities, the necessary FHIR resources and FHIR operations were profiled and extended in close cooperation with experts from Gefyra [31], who are actively involved in the German FHIR Technical Committee and provide comprehensive FHIR consultancy and training. Supported by Gefyra, numerous profiles, code systems, operation definitions and search parameters were publicly specified [32]. An implementation guide with additional explanations and relevant examples [33] was drafted in parallel.

Expanding gICS and implementing the TTP-FHIR Gateway

gICS is the data-holding system for all consent-relevant information in the outlined application scenario. This includes the reference to the research project (consent domain), the reference to the consenting person, applied consent templates, provided signatures and documented scans. Within a FHIR server, managed resources are always uniquely referenced via corresponding Universally Unique Identifiers (UUID). To provide technically valid FHIR resources via TTP-FHIR Gateway, gICS was enabled to generate these required FHIR UUIDs.

The TTP-FHIR Gateway has been implemented using the FHIR HAPI (version 5.4.0) [34]. FHIR-compatible functionalities are provided for client-side use using a gICS-related FHIR endpoint (base-URL: http[s]://<host>:<port>/ttp-fhir/fhir/gics).

The implementation comprehensively considers the profiles specified and balloted by the WGCM [26]. At the same time, it includes selected gICS-relevant extensions, for example for the implementation of consent policies in FHIR [35] (these were deliberately left out of the work of the WGCM) and for the complete mapping of all necessary information for consent templates [36] (among other things to map additional labels and properties).

In addition, several mechanisms for the customisation of FHIR consent resources, in terms of value codings and answer options, were integrated into the TTP-FHIR Gateway. This will be particularly relevant for application at NUM and MII sites.

Supporting NUM sites in the implementation

As part of the MII, University Medicine Greifswald has already prepared uniform digital consent templates in the form of a gICS-specific import format [17] based on the consent documents developed by TMF and AG Consent (Broad Consent, version 1.6.d) and made them available to all MII sites for free use and individualisation.

This consent-template was extended according to the content requirements of the NUM-specific Broad Consent (version 1.6.f) for the data protection-compliant collection and transfer of the GECCO83 data set to the central platform CODEX. Numerous consent policies were assigned to the individual consent modules of the template, as provided in the concepts of the TFCI [20].

The consent-template was provided with so-called “Expiration Properties” [37] in order to consider the time constraints provided by the MII (including validity of consent for 30 years, permissibility of medical data collection for 5 years). These are evaluated in real time by gICS when valid consents are requested.

Furthermore, the consent-template has been annotated with numerous “External Properties” [37] to inject FHIR-relevant information. This additional information is considered in the subsequent derivation of FHIR consent resources with TTP-FHIR Gateway and ensures technical conformity with the specifications of the TFCI (e.g. specifications for OIDs and permissible answer options) (cf. examples of FHIR consent resources in the Implementation Guide of the WGCM [38]).

Assuring semantic quality of the implemented FHIR functionalities

Pre-releases of the new and extended gICS, the TTP-FHIR gateway and the created consent template were handed over early for external evaluation to the NUM-CODEX project partner, the Medical Data Integration Center of clinical centre of the Ludwig Maximilian University of Munich (MeDICLMU). MeDICLMU conducted initial integration tests using Apache JMeter. The focus of the tests was on ensuring the semantic correctness of the FHIR consent resources generated by the TTP-FHIR Gateway.

Results

gICS is “on FHIR”

The TTP-FHIR Gateway provides a FHIR interface with selected search parameters and FHIR operations. It allows a FHIR-compliant provision of consent information, which is primarily managed by gICS, as FHIR resources. For the time being, the TTP-FHIR Gateway acts exclusively as a mapping service between FHIR calls of the requesting system and the managed functionalities of gICS (cf. Fig. 1). The necessary communication is implemented within the application server via Java Naming and Directory Interface (JNDI). The TTP-FHIR Gateway is an independent software component and relies on gICS application logic. The evaluation of the provided FHIR contents is the responsibility of the requesting system (e.g. local infrastructure component at the specific NUM site).

Fig. 1
figure 1

The modular architecture of the TTP-FHIR Gateway supports simplified provision of consent-related content from the consent management gICS as FHIR resources (The authors have the necessary rights to use the registered image trademarks of E-PIX, gPAS and gICS)

Full size image

The TTP-FHIR Gateway can be integrated into existing infrastructures with little effort. Existing application servers that already deploy a selection of TTP tools (e.g. gICS, E-PIX, gPAS or the TTP dispatcher) are simply supplemented by another deployment. After successful deployment, a gICS-specific FHIR endpoint is available for use under the specified base-URL. Securing the new FHIR interface by means of the established Single-Sign-On solution (SSO) Keycloak [39] is supported. The generic Informed Consent Management Service gICS (version 2.13.0) by default includes the implemented TTP-FHIR Gateway. It is available for download [40] in Docker-Compose-format for all NUM sites and other interested users.

FHIR functionalities comply with the new official FHIR consent profiles

The TTP-FHIR Gateway for gICS provides access to gICS consent content in accordance with the new and officially balloted FHIR consent profiles of the WGCM [26]. The functionalities identified according to the stakeholder dialogue were implemented as FHIR operations and are summarised in Table 1.

Table 1 Overview of the FHIR operations supported in the first release of the TTP-FHIR Gateway for gICS (version 2.13.0)
Full size table

With the specifications and examples made publicly available early on, interested partners and NUM sites were able to gain early insight into the progress of implementation [33] and adapt their local consent processes. The FHIR profiles of the WGCM form the formal basis of the FHIR consent exports. Additional comprehensive search parameters were defined for the gICS implementation [41]. Among other things, the characteristics of the FHIR exports for selected resource types (e.g. consent domains, consent templates and consent modules) can be controlled by specifying the _profile parameter. Thus, respective FHIR resources can be provided according to the specifications of the WGCM, but also in an extended form according to the extended FHIR profiles for gICS.

A comprehensive specification of all implemented profiles, supported FHIR search parameters and gICS-related extension profiles, required operations, considered code systems and defined value sets is publicly provided in the implementation guide [33] of the corresponding Simplifier-project curated by the Independent Trusted Third Party of the University Medicine Greifswald and Gefyra [32].

A customised consent template simplifies assurance of technical interoperability

For all NUM and MII sites, a modular consent template (cf. Fig. 2) has been provided as a supplement to the gICS release [42, 43]. This directly importable template not only implements the text specifications of the Broad Consent (version 1.6.f) [15] as consolidated by the TMF and WG Consent, but also fully considers the interoperability concept developed by the TFCI [20], which is based on globally unique object identifiers (OID) for each consent policy.

Fig. 2
figure 2

Structural representation of the provided consent template (detailed view) with TFCI-specific external properties. These are evaluated by the TTP-FHIR Gateway and considered when generating FHIR resources (The authors have the necessary rights to use the registered image trademarks of E-PIX, gPAS and gICS)

Full size image

As soon as consents based on this template are managed in gICS, these consent contents can be exported to FHIR consent resources via the TTP-FHIR Gateway. By default, gICS-specific references and codings are used for e.g. answer options in templates (FHIR questionnaires [28]), references to specific questions in consent modules (FHIR template frame [28]), and coding for policy semantics (FHIR consent.provisions [38]).

When generating FHIR resources, individualisation markers (external properties) contained within the prepared MII- and NUM-template are evaluated and interpreted by the TTP-FHIR Gateway. In this way, the customisation of FHIR consent resources could be successfully implemented according to the concepts of the TFCI and with respect to examples provided by the WGCM [28]. This includes the use of:

  1. 1.

    policy OIDs in FHIR consent resources (FHIR consent.provision.coding),

  2. 2.

    question OIDs in FHIR questionnaire resources (FHIR questionnaire.item.linkId), as well as

  3. 3.

    response options (FHIR questionnaires) and responses (FHIR questionnaire response [28]).

The advantage of this approach is that future changes to these code systems and value sets can be addressed without changing program code and only by updating the consent template. The corresponding manual presents a comprehensive overview of the supported external properties and their impact on generated FHIR representations [37].

Comprehensive examples of FHIR consent resources generated by the TTP-FHIR Gateway, based on the provided template and including necessary references to the TFCI-concept (as part of FHIR consent.provision) are available from Simplifier [44] accompanied by detailed descriptions within the Implementation Guide [33].

External partners approved semantic quality of FHIR functionalities

Based on the information and materials provided by the University Medicine Greifswald (gICS, TTP-FHIR Gateway, consent template, documentation), MeDICLMU has developed and executed test cases to validate the correctness of the generated FHIR-based consent (related to the functional scopes shown in Table 1), as well as the conformity with expectations related to request-parameters and response-error-codes as provided by the TTP-FHIR Gateway.

In summary, MeDICLMU as an independent project partner, has performed software test covering the semantic correctness (according to existing specifications [28, 33]) of the provided FHIR operations and resources through a total of 28 automated test cases (which are available upon request from the corresponding author). The test environment included the gICS 2.13.0 and TTP FHIR Gateway 2.0.0 (Snapshot Version 2021-06-21), as well as Apache JMeter 5.4.1. The defined test cases were designed and run based on provided sample data and MII BC template (1.6.f incl. Z-Module (TMF V0.8)).

In addition, inconsistent/missing http-error codes for return values were identified in 3 of the 28 test cases (10.71% of the test cases). Considering these results, the University Medicine Greifswald corrected the corresponding implementation of the TTP-FHIR Gateway and updated the documentation in the Implementation Guide accordingly.

The NUM and MII sites were centrally provided with the approved version of gICS with FHIR support (gICS version 2.13.0 with TTP-FHIR Gateway) [40], as well as a TFCI-compliant Broad Consent templates (1.6d [42] and 1.6.f [43]) on June 29th, 2021.

Rollout at the NUM sites started

The implementation of consent management at the 34 NUM sites is continuously monitored on the project´s collaboration platform [45]. As of August 20th, 2021, 17 sites currently intend to use gICS (installation successful: 10; installation in progress: 7). 10 of these sites have already imported the template provided (NUM-template with Z-module: 8; MII-template: 2). In total, 7 NUM and MII sites are already using gICS and the template productively.

Discussion

The technical implementation discussed here represents the first full implementation of the FHIR profiles of the WGCM in an open-source solution for digital consent management. These FHIR consent profiles were balloted in April 2021 and became part of the official FHIR standard (at national level in Germany) in September 2021 [46].

The FHIR implementation provided is freely available as a combination of gICS and TTP-FHIR Gateway since the end of June 2021 [40]. It represents a milestone for the NUM and MII sites to achieve the set goals of exchanging consent content in FHIR format. Due to the limited time and personnel resources in NUM, functionalities were initially prioritised and only basic functionalities were implemented. These functionalities will be iteratively extended in subsequent releases, taking user feedback into account.

The developed solution (gICS with TTP-FHIR Gateway-Extension) is explicitly not limited to an application in the context of MII and NUM. Existing gICS user projects, such as the German National Cohort (NAKO) [47] and the German Centre for Cardiovascular Research (DZHK) [48], can also export existing consents, consent templates, modules and policies in valid and tested FHIR format by simply updating to the latest version of gICS [49].

The provided consent template (MII BC 1.6.f) encapsulates the necessary prior technical knowledge to generate FHIR consent resources conforming to the specifications of the TFCI concepts and to consider them consistently and uniformly. The provision of gICS, TTP-FHIR Gateway and the consent-template are an offer to the NUM and MII sites. Their use simplifies and supports the uniform exchange of health data between the NUM sites and the central research platform in conformance with the patients’ consents. It is up to each site to accept this offer and to integrate these tools into local Trusted Third-Party processes and, thus, reduce necessary technical efforts for a HL7 FHIR- and TFCI-compliant consent management.

Nevertheless, this requires obtaining the corresponding ethics approval of the local ethics as well as necessary local processes for informing the patient, obtaining and documenting consent and realisation of corresponding withdrawal processes, which is also complex and individual for each site.

Conclusions

In late 2020, the NUM and MII sites have made a binding commitment to set up local infrastructures and establish required local consent processes to enable a data protection-compliant export of GECCO83 data items (based on HL7 FHIR) to the central research platform CODEX to support research on COVID-19 and to demonstrate the necessary degree of preparedness for future pandemic situations in Germany.

In the first funding phase of NUM-CODEX, a FHIR-based representation of informed consent, based on the MII Broad Consent (MII BC), signed by the patient and automatically enforceable, was to be transferred in addition to the patient’s medical data. This should not only comply with the new HL7 FHIR consent profiles [28], but also with the interoperable implementation concept of the TFCI [20].

In order to support the 34 NUM sites in this challenge, this article has shown that the technical prerequisites for a FHIR-compliant and interoperable provision of consent information could be achieved with the help of the consent management gICS and the provided TTP-FHIR Gateway [40].

The successfully implemented TTP-FHIR Gateway for gICS enables the FHIR compliant provision of consent information. This solution can be used for existing and future user projects of gICS. It can as well support the implementation of FHIR-oriented infrastructures and data-protection-compliant processes. The TTP-FHIR Gateway supports the balloted FHIR consent profiles of the HL7 Working Group Consent Management [28]. All gICS-specific extensions were specified and publicly documented with the support of FHIR experts [31]. The initial functional scope of the TTP-FHIR Gateway coincides with the requirements identified in the NUM-CODEX setting. The semantic correctness of these functionalities was tested by externally conducted tests at the clinical centre of the Ludwig-Maximilian University Munich. In order to simplify the technical application of the MII BC and the corresponding implementation of the TFCI interoperability concept at the NUM sites, a pre-configured consent template was created in accordance with specifications of the MII BC [13, 15] and was provided to all NUM partner sites [42, 43].

In the NUM-CODEX project, the interaction of gICS and HL7 FHIR in terms of content and technology was successfully demonstrated using the example of the MII BC. The implementation approach explained can be used for the currently known variants of the MII BC. Moreover, this approach can easily be customised for application in additional scenarios out of the MII BC.

This is particularly advantageous, if it should not be possible to establish the MII BC at selected university hospitals due to ethical or legal concerns. In this case, alternative options for the export of pseudonymised data to NUM-CODEX could be considered. (e.g. use of research data from other local COVID-19 projects collected on the legal basis of individual consent documents). The clarification of the permissibility of this procedure would, of course, primarily be a legal-ethical question. A technical implementation can only be considered, if the informational self-determination of the patient is not impaired.

Availability of data and materials

The consent management software (gICS 2.13.0 with TTP-FHIR Gateway) [40], the consent templates developed for documentation of MII- and NUM-CODEX consents [42, 43] and the referenced FHIR Consent profiles [46] are publicly available.

Abbreviations

APPC:

Advanced Patient Privacy Consent

BPPC:

Basic Patient Privacy Consents

CODEX:

COVID-19 Data Exchange Platform

DSF:

Data Sharing Framework

FHIR®:

Fast Healthcare Interoperable Resources

GDPR:

EU General Data Protection Regulation

gICS®:

Generic Informed Consent Service

GTH:

Gecco Transfer Hub

HL7®:

Health Level Seven International

IHE:

Integrating the Healthcare Enterprise

JNDI:

Java Naming and Directory Interface

MeDICLMU :

Medical Data Integration Center of the clinical centre of the Ludwig Maximilian University of Munich

MII:

Medical Informatics Initiative

MII BC:

MII Broad Consent

MIRACUM:

Medical Informatics in Research and Care in University Medicine (MI-I Consortium)

NUM:

Network of university medicine (NUM) to support COVID and pandemic research at national level in Germany

TFCI:

MII Task Force Consent Implementation

TMF:

Technology, Methods, and Infrastructure for Networked Medical Research e.V. (Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V.)

TTP:

Trusted Third Party

UMG:

University Medicine Greifswald

WG Consent:

MII Working Group Consent

WGCM:

Working Group Consent Management

References

  1. Prokosch HU, Bahls T, Bialke M, Eils J, Fegeler C, Gruendner J, et al. The COVID-19 data exchange platform of the German university medicine. Stud Health Technol Inform. 2022;294:674–8. https://doi.org/10.3233/SHTI220554.

    Article  Google Scholar 

  2. Netzwerk-universitaetsmedizin.de. NUM Project CODEX. https://www.netzwerk-universitaetsmedizin.de/projekte/codex (2021). Accessed 03 Aug 2021.

  3. Netzwerk-universitaetsmedizin.de. GECCO-Dataset. https://www.netzwerk-universitaetsmedizin.de/gecco-data-set (2021). Accessed 03 Aug 2021.

  4. Sass J, Bartschke A, Lehne M, Essenwanger A, Rinaldi E, Rudolph S, et al. The German Corona Consensus Dataset (GECCO): a standardized dataset for COVID-19 research in university medicine and beyond. BMC Med Inform Decis Mak. 2020;1:341. https://doi.org/10.1186/s12911-020-01374-w.

    Article  Google Scholar 

  5. Intersoft consulting. Art. 6 General Data Protection Regulation, Lawfulness of processing. https://gdpr-info.eu/art-6-gdpr/ Accessed 01 Mar 2018.

  6. Independent Trusted Third Party of the University Medicine Greifswald. E-PIX® supports Privacy-Preserving-Record-Linkage (PPRL): New Version 2.12.0 available (German). https://www.ths-greifswald.de/e-pix-2-12-0/ (2021). Accessed 30 Jun 2021.

  7. Hund H, Wettstein R, Heidt CM, Fegeler C. Executing distributed healthcare and research processes—the HiGHmed data sharing framework. Stud Health Technol Inform. 2021;278:126–33. https://doi.org/10.3233/SHTI210060.

    Article  Google Scholar 

  8. Prokosch HU, Acker T, Bernarding J, Binder H, Boeker M, Boerries M, et al. MIRACUM: medical informatics in research and care in university medicine. Methods Inf Med. 2018;57(S01):e82–91. https://doi.org/10.3414/ME17-02-0025.

    Article  Google Scholar 

  9. Haarbrandt B, Schreiweis B, Rey S, Sax U, Scheithauer S, Rienhoff O, et al. (2018) HiGHmed—an open platform approach to enhance care and research across institutional boundaries. Methods Inf Med 57(S 01): e66-e81. https://doi.org/10.3414/ME18-02-0002.

  10. Winter A, Stäubert S, Ammon D, Aiche S, Beyan O, Bischoff V, et al. Smart medical information technology for healthcare (SMITH). Methods Inf Med. 2018; 57(S 01): e92-e105. https://doi.org/10.3414/ME18-02-0004.

  11. Prasser F, Kohlbacher O, Mansmann U, Bauer B, Kuhn K. Data integration for future medicine (DIFUTURE). Methods of Inf Med 2018 57(S 01): e57-e65. https://doi.org/10.3414/ME17-02-0022.

  12. Hampf C, Bialke M, Geidel L, Vass A, Bahls T, Blasini R, et al. A survey on the current status and future perspective of informed consent management in the MIRACUM consortium of the German Medical Informatics Initiative. Transl Med Commun. 2021;6(1):7. https://doi.org/10.1186/s41231-021-00086-1.

    Article  Google Scholar 

  13. MII Consent Working Group. MII Broad Consent - Patient Consent Form Template, Version 1.6d (German). https://www.medizininformatik-initiative.de/sites/default/files/2020-04/MII_AG-Consent_Einheitlicher-Mustertext_v1.6d.pdf (2020). Accessed 14 Aug 2021.

  14. Zenker S, Strech D, Ihrig K, Jahns R, Müller G, Schickhardt C, et al. Data protection-compliant broad consent for secondary use of health care data and human biosamples for (bio)medical research: towards a new German national standard. J Biomed Inform. 2022. https://doi.org/10.1016/j.jbi.2022.104096.

    Article  Google Scholar 

  15. MII Consent Working Group. MII Broad Consent - Patient Consent Form Template with additional Module for NUM-CODEX, Version 1.6f (German). https://www.medizininformatik-initiative.de/sites/default/files/2021-08/MII_AG-Consent_Einheitlicher-Mustertext_v1.6f_v08.pdf (2021). Accessed 26 Aug 2021.

  16. intersoft consulting. GDPR Key Issues "Third Countries". https://gdpr-info.eu/issues/third-countries/ (2021). Accessed 20 Sep 2021.

  17. Bialke M, Bahls T, Geidel L, Rau H, Blumentritt A, Pasewald S, et al. MAGIC: Once Upon a time in consent management—a FHIR tale. J Transl Med. 2018;16:256. https://doi.org/10.1186/s12967-018-1631-3.

    Article  Google Scholar 

  18. Bild R, Bialke M, Buckow K, Ganslandt T, Ihrig K, Jahns R, et al. Towards a comprehensive and interoperable representation of consent-based data usage permissions in the German Medical Informatics Initiative. BMC Med Inform Decis Mak. 2020;1:103. https://doi.org/10.1186/s12911-020-01138-6.

    Article  Google Scholar 

  19. MII Task Force "Consent Implementation". ART-DECOR MII Consent Answer Value Set. https://art-decor.org/decor/services/RetrieveValueSet?id=2.16.840.1.113883.3.1937.777.24.11.30&effectiveDate=2021-03-23T23:45:09&language=en-US (2020). Accessed 12 May 2021.

  20. MII Task Force "Consent Implementation". ART-DECOR MII Consent Policy ValueSet. https://art-decor.org/decor/services/RetrieveValueSet?id=2.16.840.1.113883.3.1937.777.24.11.36&language=en-US (2021). Accessed 05 May 2021.

  21. Bialke M, Penndorf P, Wegner T, Bahls T, Havemann C, Piegsa J, et al. A workflow-driven approach to integrate generic software modules in a Trusted Third Party. J Transl Med. 2015. https://doi.org/10.1186/s12967-015-0545-6.

    Article  Google Scholar 

  22. Pommerening K, Drepper J, Helbing K, Ganslandt T. Guideline for Data Protection in Medical Research Projects: TMF's generic solutions 2.0. 1st ed. Berlin; 2014.

  23. miracum.org. MIRACUM - Overview of the MIRACOLIX Tools 2.0. https://www.miracum.org/das-konsortium/datenintegrationszentren/miracolix-tools/ (2022). Accessed 24 Nov 2022.

  24. medizininformatik-initiative.de. University medicine starts patient consent with broad consent (German). https://www.medizininformatik-initiative.de/de/universitaetsmedizin-greifswald-startet-patienteneinwilligung-mit-broad-consent (2020). Accessed 14 Aug 2020.

  25. Independent Trusted Third Party of the University Medicine Greifswald. Consent Management gICS - Web-Interface Specification Version 2.13.0. https://www.ths-greifswald.de/gics/doc/2-13-0 (2021). Accessed 29 Jun 2021.

  26. HL7 Germany. Simplifier-Project of the HL7 Working Group Consent Management (German). https://simplifier.net/Einwilligungsmanagement (2021). Accessed 01 May 2021.

  27. IHE ITI Technical Committee. Advanced Patient Privacy Consent (APPC) - Draft for public comment. (2016) https://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_APPC_Rev1.0_PC_2016-05-27.pdf Accessed 03 Feb 2018.

  28. HL7 Germany. Simplifier Implementation Guide of the HL7 Working Group Consent Management (German). https://simplifier.net/guide/einwilligungsmanagement/igeinwilligungsmanagement (2021). Accessed 01 May 2021.

  29. HL7 FHIR. Codesystem Consent-Provision-Type. https://www.hl7.org/fhir/codesystem-consent-provision-type.html (2021). Accessed 08 Jul 2021.

  30. Independent Trusted Third Party of the University Medicine Greifswald. Consent Management gICS - Web-Interface Specification Version 2.12.0. https://www.ths-greifswald.de/gics/doc/2-12-0 (2020). Accessed 01 Dec 2020.

  31. Gefyra. Gefyra.info. https://gefyra.info/ (2022). Accessed 24 Nov 2022.

  32. Independent Trusted Third Party of the University Medicine Greifswald. Simplifier-Project of the Independent Trusted Third Party of the University Medicine Greifswald (German). https://simplifier.net/ths-greifswald/~introduction (2021). Accessed 01 Jun 2021.

  33. Independent Trusted Third Party of the University Medicine Greifswald. Implementation Guide TTP-FHIR Gateway for Consent Management (German). https://ths-greifswald.de/gics/fhir (2022). Accessed 24 Nov 2022.

  34. hapifhir.io. HAPI FHIR - Open source implementation of the HL7 FHIR standard for healthcare interoperability in Java. https://hapifhir.io/ (2021). Accessed 08 Jul 2021.

  35. Independent Trusted Third Party of the University Medicine Greifswald. Simplifier-Project of the Independent Trusted Third Party of the University Medicine Greifswald - Consent Policy Profile (German). https://simplifier.net/ths-greifswald/consentpolicy (2022). Accessed 24 Nov 2022.

  36. Independent Trusted Third Party of the University Medicine Greifswald. Simplifier-Project of the Independent Trusted Third Party of the University Medicine Greifswald - Consent Template Profile (German). https://simplifier.net/ths-greifswald/consenttemplate (2022). Accessed 24 Nov 2022.

  37. Independent Trusted Third Party of the University Medicine Greifswald. Consent Management gICS - User Manual (German). https://www.ths-greifswald.de/gics/handbuch/2-13-0 Accessed 29 Jun 2021.

  38. HL7 Germany. Implementation Guide of the HL7 Working Group Consent Management - Examples for FHIR Consent (German). https://ig.fhir.de/einwilligungsmanagement/stable/Consent.html (2022). Accessed 24 Nov 2022.

  39. keycloak.org. Keycloak - Open Source Identity and Access Management. https://www.keycloak.org/ (2021). Accessed 01 Jun 2021.

  40. Independent Trusted Third Party of the University Medicine Greifswald. Consent Management gICS - Download. https://www.ths-greifswald.de/forscher/gics/#download (2021). Accessed 29 Sep 2021.

  41. Independent Trusted Third Party of the University Medicine Greifswald. Implementation Guide TTP-FHIR Gateway - Questionnaire Search Parameters (German). https://www.ths-greifswald.de/fhir/ig/2-2-0 (2022). Accessed 24 Nov 2022.

  42. Independent Trusted Third Party of the University Medicine Greifswald. MII Broad Consent Version 1.6d - gICS-Template (JSON). https://www.ths-greifswald.de/gics/templates/mii/1.6.d (2021). Accessed 03 Mar 2021.

  43. Independent Trusted Third Party of the University Medicine Greifswald. MII Broad Consent Version 1.6f for NUM-CODEX - gICS-Template (JSON). https://www.ths-greifswald.de/gics/templates/mii/1.6.f (2021). Accessed 29 Jun 2021.

  44. Independent Trusted Third Party of the University Medicine Greifswald. Simplifier Implementation Guide TTP-FHIR Gateway - Examples Consent Bundle (German). https://simplifier.net/ths-greifswald/~resources?category=Example&exampletype=Bundle (2021). Accessed 29 Jun 2021.

  45. FAU. NUM-CODEX Project-Confluence - Consent Management Monitoring (non-public content). https://confluence.imi.med.fau.de/pages/viewpage.action?spaceKey=MIIC&title=Monitoring+Einwilligungsmanagement (2021). Accessed 20 Aug 2021.

  46. HL7 Germany. Official Implementation Guide of the HL7 Working Group Consent Management (Version 1.0.1). https://ig.fhir.de/einwilligungsmanagement/1.0.1/ (2022). Accessed 24 Nov 2022.

  47. German National Cohort (GNC) Consortium. The German National Cohort: aims, study design and organization. European Journal of Epidemiology. 2014;29(5): 371–382. https://doi.org/10.1007/s10654-014-9890-7.

  48. German Centre for Cardiovascular Research (DZHK). dzhk.de. https://dzhk.de/forschung/publikationen/publikationen-2021/ (2021). Accessed 10 May 2021.

  49. miracum.org. Comprehensive Update: A fresh breeze sweeps the MIRACOLIX toolbox. https://www.miracum.org/news/comprehensive-update-a-fresh-breeze-sweeps-the-miracolix-toolbox/ (2021). Accessed 28 Jul 2021.

Download references

Acknowledgements

Not applicable.

Funding

Open Access funding enabled and organized by Projekt DEAL. The NUM-CODEX project is funded by the Federal Ministry of Education and Research of Germany (BMBF) (grant number 01KX2021). Selected authors of this publication accompany the work of the MII Task Force Consent Implementation on behalf of the MII consortia SMITH (German Federal Ministry of Education and Research, grant number 01ZZ1803A) and MIRACUM (German Federal Ministry of Education and Research, grant number 01ZZ1801M). The funders had no role in the design of the study, the collection, analysis or interpretation of data, or the writing of the manuscript.

Author information

Author notes

  1. Martin Bialke and Lars Geidel have contributed equally to this work

Authors and Affiliations

  1. Institute for Community Medicine, Department Epidemiology of Health Care and Community Health, University Medicine Greifswald, Ellernholzstr. 1-2, 17475, Greifswald, Germany

    Martin Bialke, Lars Geidel, Christopher Hampf, Arne Blumentritt, Peter Penndorf, Ronny Schuldt, Frank-Michael Moser, Thomas Bahls & Wolfgang Hoffmann

  2. Gefyra GmbH, Otto-Hahn-Str. 9, 48161, Münster, Germany

    Stefan Lang

  3. MOLIT Institute Heilbronn, Im Zukunftspark 10, 74076, Heilbronn, Germany

    Patrick Werner

  4. Institute for Medical Informatics, Statistics and Epidemiology (IMISE), Leipzig University, Härtelstr. 16-18, 04107, Leipzig, Germany

    Sebastian Stäubert

  5. SMITH Consortium of the German Medical Informatics Initiative, Leipzig, Germany

    Sebastian Stäubert

  6. GECKO Institute, Heilbronn University of Applied Sciences, Max-Planck-Str. 39, 74081, Heilbronn, Germany

    Hauke Hund

  7. Medical Data Integration Center (MeDIC LMU), Hospital of the Ludwig-Maximilian-University (LMU), Marchioninistr. 15, 81377, Munich, Germany

    Fady Albashiti

  8. Tekaris GmbH (Partner of MeDIC LMU), Elsenheimerstraße 53, 80687, Munich, Germany

    Jürgen Gührer

  9. Chair of Medical Informatics, Friedrich-Alexander-Universität Erlangen-Nürnberg, Wetterkreuz 15, 91058, Erlangen, Germany

    Hans-Ulrich Prokosch

Authors
  1. Martin Bialke
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Lars Geidel
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Christopher Hampf
    View author publications

    You can also search for this author in PubMed Google Scholar

  4. Arne Blumentritt
    View author publications

    You can also search for this author in PubMed Google Scholar

  5. Peter Penndorf
    View author publications

    You can also search for this author in PubMed Google Scholar

  6. Ronny Schuldt
    View author publications

    You can also search for this author in PubMed Google Scholar

  7. Frank-Michael Moser
    View author publications

    You can also search for this author in PubMed Google Scholar

  8. Stefan Lang
    View author publications

    You can also search for this author in PubMed Google Scholar

  9. Patrick Werner
    View author publications

    You can also search for this author in PubMed Google Scholar

  10. Sebastian Stäubert
    View author publications

    You can also search for this author in PubMed Google Scholar

  11. Hauke Hund
    View author publications

    You can also search for this author in PubMed Google Scholar

  12. Fady Albashiti
    View author publications

    You can also search for this author in PubMed Google Scholar

  13. Jürgen Gührer
    View author publications

    You can also search for this author in PubMed Google Scholar

  14. Hans-Ulrich Prokosch
    View author publications

    You can also search for this author in PubMed Google Scholar

  15. Thomas Bahls
    View author publications

    You can also search for this author in PubMed Google Scholar

  16. Wolfgang Hoffmann
    View author publications

    You can also search for this author in PubMed Google Scholar

Contributions

Drafting of the manuscript: MB, LG, CH, SL. Creation of figures and tables: MB. Development of gICS: LG, AB, MB, CH, RS, FMM. Concept and implementation of the TTP-FHIR Gateway: MB, PP. FHIR Profiling and implementational consulting: SL, PW. Semantic Tests: FA, JG. Revision of the manuscript: MB, LG, CH, AB, RS, FMM, PP, SL, PW, SS, HH, HUP, TB, WH. All authors read and approved the final manuscript.

Corresponding author

Correspondence to Martin Bialke.

Ethics declarations

Ethics approval and consent to participate

Not applicable.

Consent for publication

Not applicable.

Competing interests

The authors declare that they have no competing interests.

Additional information

Publisher's Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Rights and permissions

Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/. The Creative Commons Public Domain Dedication waiver (http://creativecommons.org/publicdomain/zero/1.0/) applies to the data made available in this article, unless otherwise stated in a credit line to the data.

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Bialke, M., Geidel, L., Hampf, C. et al. A FHIR has been lit on gICS: facilitating the standardised exchange of informed consent in a large network of university medicine. BMC Med Inform Decis Mak 22, 335 (2022). https://doi.org/10.1186/s12911-022-02081-4

Download citation

  • Received:

  • Accepted:

  • Published:

  • DOI: https://doi.org/10.1186/s12911-022-02081-4

Keywords

BMC Medical Informatics and Decision Making

ISSN: 1472-6947

Contact us