Gaia-X-Med: Experiences with Building Dataspaces for Medical Applications

Abstract

Gaia-X, a European initiative, aims to create a digital sovereignty framework for service ecosystems in the future Internet. Its applicability to the health domain was explored in the Gaia-X-Med project, which aimed to establish a common dataspace for various medical use cases based on Gaia-X principles. This paper presents a trust- and consent-based approach to the secure authentication and digital contract negotiation central to this endeavor and discusses the challenges that arose during the adoption of the Gaia-X framework, particularly relating to the strict requirements of the European healthcare domain with regards to privacy and consent regulations. By exploring the practical implications of Gaia-X in the healthcare context, this paper aims to contribute to the ongoing discussions surrounding the digital sovereignty of both citizens and corporations, as well as its realization via future Internet technologies.

1. Introduction

Gaia-X (https://www.gaia-x.eu/ (accessed on 5 December 2024)) is a European initiative aimed at creating a sovereign data infrastructure. Launched in 2019, it seeks to establish a federated ecosystem where data can be shared and processed securely and transparently within Europe. The project aims to ensure data sovereignty by keeping data within European borders, protecting it from foreign influence, and promoting European technological leadership (https://digital-strategy.ec.europa.eu/en (accessed on 5 December 2024)). Gaia-X also emphasizes interoperability and standardization to facilitate data exchange between different platforms and providers. It is a key initiative shaping the future of the Internet, by building a trusted, decentralized, and interoperable digital ecosystem that emphasizes data sovereignty, security, and transparency—crucial elements for the future Internet. By enabling federated cloud services and promoting European standards, Gaia-X can contribute to a more open, secure, and user-centric Internet, which aligns with the goals of the future Internet vision, where data flow freely but securely across borders, industries, and applications.

Gaia-X is a highly complex initiative, with numerous white papers detailing its architecture, principles, and vision for a federated European data infrastructure. While some early implementations have emerged, demonstrating the potential of Gaia-X in sectors like cloud services and data sharing, building fully Gaia-X-conformant solutions remains a significant challenge. The intricacies of aligning with its strict standards, such as data sovereignty, interoperability, and transparency, present hurdles for businesses and developers. Moreover, the integration of diverse cloud providers, adherence to European regulations, and ensuring seamless data portability across borders further complicate the path to widespread Gaia-X adoption.

Within the framework of the project Gaia-X-Med, we explored the application of Gaia-X concepts within the healthcare sector, in order to analyze how the Gaia-X infrastructure can drive innovation in healthcare, improve patient outcomes, and support the development of personalized medicine, while maintaining compliance with strict regulatory frameworks like GDPR (General Data Protection Regulation (https://gdpr.eu (accessed on 5 December 2024)). By leveraging Gaia-X’s principles of data sovereignty, security, and interoperability, Gaia-X-Med aimed to facilitate secure data sharing and collaboration between healthcare providers, researchers, and medical institutions. In six use cases, the project addressed critical challenges such as ensuring patient data privacy, enabling cross-border data exchange, and enhancing access to medical information for research and treatment purposes.

This paper presents the main results of Gaia-X-Med. It evaluates the Gaia-X approach for its ability to enable data exchange in service ecosystems, as applied to six use cases from the health domain. In order to do so, we adapted the Gaia-X concepts to fit the requirements of those use cases, and we report on the results and a number of lessons learned.

The remainder of this paper is structured as follows: Section 2 gives an overview of existing approaches for realizing data sovereignty and trust, and presents existing software implementations. Section 3 introduces the Gaia-X-Med project and outlines the framework for the six eHealth use cases examined, highlighting their unique requirements and relevance to Gaia-X principles. Section 4 delves into the core Gaia-X concepts, including the modifications made to align with healthcare-specific demands. In Section 5, we provide a detailed analysis of the Gaia-X-related implementation of these use cases, with a focus on ensuring trust and secure data sharing within federated healthcare networks. Section 6 presents insights and lessons learned, as well as challenges encountered during the project execution, which illustrate both the potential and limitations of Gaia-X in healthcare applications. Finally, Section 7 concludes the paper, proposing directions for future research that could enhance Gaia-X’s applicability in healthcare data ecosystems.

2. Related Work

In this section, we review the existing literature on the concepts of GAIA-X, emphasizing how this paper builds upon and extends these foundations. We also examine current implementations that support GAIA-X, outlining the enhancements introduced by our work. While this section provides a high-level overview, detailed comparisons and analyses are presented in the subsequent sections.

2.1. Data Sovereignty and Trust

Data sovereignty, for a long time a somewhat fuzzy and mainly political term, has grown to have a more precise technical meaning: to remain in control of one’s personal data. In the context of data exchanges in a digital service economy, this principle has become central to many dataspace concepts, with decentralized federations of participants with full control over their data up to the point of the actual exchange. Many requirements and challenges have been identified, among them the interoperability within the dataspaces, but also the trust among the participants [1,2,3,4,5], and even relating to data security after the exchange [6]. These challenges are also pertinent to our work. However, a critical aspect we must address—unlike previous efforts—is managing user consent, ensuring that individuals have explicitly agreed to allow their data to be used by third parties, such as for research purposes.

The long-standing effort to realize such dataspaces culminated in the International Data Spaces (IDS) initiative (https://internationaldataspaces.org/ (accessed on 5 December 2024)), whose concepts and implementations [7,8] provided the basis for the Gaia-X specification documents. Aligned with the principles of GAIA-X, our work builds upon these efforts. However, GAIA-X provides considerable flexibility in how these principles are implemented. In Section 4, we will detail our specific implementation and the extensions we have developed for the medical domain.

Gaia-X-based approaches have been demonstrated to be successful in some application domains, especially mobility [9] (https://gaia-x4ki.eu/en (accessed on 5 December 2024)), with promising approaches in others such as smart cities [10] and agriculture [11]. Many of these approaches not only exemplify implementations of GAIA-X concepts but also share a common technical foundation in the form of frameworks. However, the health domain requires specialized extensions, particularly for managing consent—an area addressed through the enhancements proposed in this paper. A detailed discussion of existing work and our contributions is provided in Section 2.2.

Due to both conceptual shortcomings and the lack of extensions mentioned above, the same kind of successful general application of Gaia-X approaches has so far not be seen within the health domain, although it has been attempted, e.g., by [12]. Our paper introduces new conceptual and technical solutions, along with valuable lessons learned, to support the broader application of GAIA-X concepts in the health domain.

Health is also a strong focus of the German Gaia-X-Hub, an official Gaia-X institution, since it was conceived with the majority of use cases situated in health [13], including two of its lighthouse projects, Health-X [14] and Team-X [15]. Through extensive scientific collaboration with these two projects, we identified similar challenges in applying GAIA-X to the healthcare domain. However, GAIA-X-Med, Team-X, and Health-X have each adopted slightly different conceptual approaches and technical implementations. Our solution is detailed in Section 4.3, but a comprehensive comparison with the approaches developed by the other two projects remains for future work, as those initiatives are still ongoing. Despite the many health-related efforts and the focus of the Gaia-X-Hub, successful Gaia-X-based approaches have not been demonstrated to the same degree as in other domains, and standardized, interoperable implementations have not appeared or been as widely used. Therefore, in this paper, we will show a different approach, to also provide Gaia-X services to the health domain, keeping in mind the important requirements identified in the earlier works reported on above.

In addition to Gaia-X, thereave been other initiatives for providing trusted secure data infrastructures for the health domain. The Medical Informatics Initiative (https://www.medizininformatik-initiative.de/en/start (accessed on 5 December 2024)), e.g., advocates for a more sovereign data exchange, and many far-reaching projects are being developed, such as the European Health Data Space (EHDS) (https://health.ec.europa.eu/ehealth-digital-health-and-care/european-health-data-space_en (accessed on 5 December 2024)) [16] and electronic health records (e.g., in Germany: “elektronische Patientenakte” (ePA)), (https://www.bundesgesundheitsministerium.de/elektronische-patientenakte (accessed on 5 December 2024)) as well as many other non-Gaia-x health data exchange projects [17,18]. So far, these approaches have only been nationally relevant, not as far-reaching as Gaia-X, or, as in the case of the EHDS, still at a rather conceptional level (the EHDS was agreed upon in spring 2024); however, an integration of these efforts and their learnings with Gaia-X concepts would provide a valuable foundation for further research. Nonetheless, all this shows the importance of this topic for the future Internet.

2.2. Existing Software Implementations

We now present the relevant Gaia-X-related software packages we examined to determine the extent to which we could use them as a basis for our own work or whether they already offer complete solutions.

The Cross-Federation Service Components (XFSC), formerly GXFS, implemented many of the Gaia-X concepts, not just those relating to trust [19]. However, it suffers (at the time of our project) from stability and documentation issues, making it difficult to employ.

The Eclipse Dataspace Components (EDC) represents a dataspace connector that is mainly concerned with what Gaia-X calls data exchange and has its roots in the International Data Spaces project [20]. Similarly to XFSC, it is a highly complex system and remains (at the time of our project) under constant development. In addition, as a connector, it is server-like and always online, even on the consumer side, which is not an appropriate design choice, as users cannot be expected to be continuously online.

Since we focus mainly on trust and consent, our aim was to reduce the complexity of using a framework. Therefore, we decided against both. Moreover, for the success of our project, we had to rely on stable (or at least controllable) versions of the underlying framework. Hence, we decided to compile our own framework, but relying on the major concepts and partly also on implementations of both XFSC and EDC. We based our implementation on the same underlying technologies as XFSC and incorporated parts of XFSC with little configuration or modification, like the compliance service. From EDC, we especially used the concept of contracts. Moreover, we extended the latter to support asynchronous services. Details can be found in Section 3.

3. Defining the Use Cases: The Gaia-X-Med Project

A total of four university research institutes, four clinics and eight companies were involved in the Gaia-X-Med project. Through this composition, we made sure that the results were not purely theoretical, but transferred and evaluated by clinical and industrial partners.

3.1. The Six Use Cases

Each of the six medical use cases of Gaia-X-Med focused on one application, thus they covered a broad spectrum of the eHealth domain. Some of the applications are intended for commercial use, some for research use, some are mainly developed by companies, some mainly by researchers, some of them are customer-facing, some target medical professionals, some represent business-to-business (B2B) cooperation between companies and hospitals, and some service official national institutions to fulfill their monitoring duties. They all incorporate various data sources with differing levels of associated privacy regulations, from non-personal temperature sensor data to the personal, biometric data of individual patients. Therefore, several different data protection measures come into play, ranging from custom concepts regarding broad consent (https://www.medizininformatik-initiative.de/en/template-text-patient-consent-forms (accessed on 5 December 2024)) for research use to individual patient consent. Generally speaking, if the personal data of individual persons are involved, they are entitled to a certain set of rights due to the GDPR and related regulations. To give a short overview, personal data here in particular refer to sets of data which can be associated with an individual, both general, such as name, age, nationality, height, weight, etc, but also biometric, such as fingerprints or images of the face or eyes. Even some medical images like from radiology can be considered biometric, and are thus personal and subject to the GDPR. The rights it affords to individuals include the right to delete no longer critical personal data, to forbid the transfer to third parties, to request the complete delivery of all data, and more. In practice, this requires individual patients to give explicit consent to the transfer of any of their personal data for any reason. To address this, our use cases employ custom data protection agreements, explicit patient consent forms or broad consent, covering the most common approaches to this requirement.

In the following, we briefly present each use case in detail (see also Figure 1):

Use

Case 1 (in red in the figure)—AI-based process optimization for radiology. The exchange of radiologic images has been standardized in DICOM (https://www.dicomstandard.org/ (accessed on 5 December 2024)) and represents a opportunity for collaboration between hospitals and companies to improve diagnosis, possibly enhanced by AI. DICOM data consist of CRT, MRI, or x-ray images, alongside information about the patient like name, date of birth, and identification number; about the image, such as resolution; and about the imaging device, like calibrations. The seamless exchange of these data technically and organizationally, however, remains challenging, thus a device accessing the CT/MRT device producing radiological data was developed to ease this process. This commercial B2B application for hospitals has to respect strict regulations due to its commercial use of personal, and even biometric data, of individual patients and thus involves a custom data protection concept, possibly including ethical approval and patient consent forms, as well as medical device development regulation.

Use

Case 2 (blue)—Integration of patient data for individual ablation therapy. Ablation therapy is a suggested treatment for certain heart diseases, but its effectiveness varies based on many parameters. To improve its efficacy, three-dimensional cardiologic images of treated patients are collected and a model is trained to predict expected outcomes for patients with similar characteristics. Furthermore, to improve the accuracy of this prediction, long-term outcomes and risk factors are identified by also incorporating routine patient data like age, height, weight, chronic illnesses other than the heart diseases in question of both affected and unaffected patients into the model. This prediction is presented as an application for research use by medical professionals, relying on the personal and biometric data of individual patients, requiring their consent, as well as anonymized routine data, which could be obtained via ethical approval by an associated hospital’s data integration center (DIC), the data of which are collected with broad consent for research use.

Use

Case 3 (green)—AI-based home monitoring of eye diseases. Regularly obtaining OCT images of the eye can improve the diagnosis and rehabilitation recommendations made by medicinal professionals. The OCT devices provided to patients at home help in obtaining these images and strongly improve patient acceptance, while the automatic segmentation provided by a commercial application for medical professionals further assists in making treatment decisions. The employed data are personal and biometric, and their usage requires individual patient consent when using the OCT device and sending the data to be segmented. At the same time, the segmentation process itself may be improved further using these data or is itself based upon other personal patient data, which in turn will need and would have needed individual patient consent for this type of usage.

Use

Case 4 (yellow)—AI-based causal inference. Classifying genetic predispositions remains an interesting field of research. Connecting the researchers working on classification algorithms and AI models with other researchers able to provide the genetic datasets to train them is facilitated by an open collaborative platform. This application for research use requires data protection measures for each collaboration taking place. If one researcher intends to provide data for another, the initial data protection concept of when the data were collected has to be checked for whether it permits this forwarding, as far as it is possible with broad consent. Additionally, if classification was to be performed on actual patients, additional regulations would apply.

Use

Case 5 (black and white)—HACCP in a Smart Hospital. The state veterinary office has a duty to monitor hygiene processes in hospitals. In order to facilitate this, hygiene sensors—particularly temperature sensors in freezers—are deployed in the hospital and a monitoring application is developed. This commercial application for a state institution has few regulations regarding the privacy of the collected data, since the exchanged data are not personal.

Use

Case 6 (grey)—Decision Support System. The domain knowledge of medical experts can be formalized as models. Using large language models (LLMs) to generate textual explanations from these models can be useful for providing diagnosis assistance to medical professionals. A research use application for medical professionals is developed that does not rely on individual patient data but rather on models created by experts, often based on medical literature or guidelines, and is thus not subject to the associated data protection regulations.

In each use case, a Gaia-X-based demonstrator shows the feasibility of the concept, keeping in mind the associated data protection regulations, which typically represent a major challenge during the development of eHealth applications, so as to lay a foundation for later commercialization, if intended. In the following, we take a closer look at the use cases’ requirements with respect to Gaia-X’s services.

3.2. Requirements of the Use Cases for Gaia-X

The use cases are centered around different applications, each with different requirements but also some common challenges, mainly the secure exchange of data between specific stakeholders while respecting data protection regulations. The main stakeholders for all use cases each have their own intentions (see Figure 2):

• Hospitals, as well as doctor’s offices, want to provide patients with their data and also to use it internally, if possible.
• Companies want to generate value from data by creating commercial services and products from it.
• Patients want to maintain their data sovereignty, including full control over access and distribution.
• Researchers want use patient data for research, and share the results, including the data they are based on.
• DICs aim to provide patient data to researchers, after anonymization and ethical approval.

Acting upon these intentions requires the involved stakeholders to enter into certain agreements, so that their interactions respect the data protection rights of all parties involved. These agreements range from cooperation contracts between institutions like hospitals and companies, to usage contracts with patients as the user of a company’s offering, to consent management agreements between patients, researchers, and data integration centers.

They all have to be agreed upon beforehand, before any data are exchanged, since many of them represent the consent to the exchange itself. The content of agreements has to be informative enough for all parties to make an informed decision about consent, especially in the case of individual patients. The given information has to be correct and both parties should be able to verify it, preferably via a neutral third party with sufficient credibility. Underlying all of this is the mutual trust in the other involved parties, which in a digital context has to be based on verifiable identities and information, as well as a legal framework in the case of misbehavior. Therefore, in summary, the stakeholders in the use cases want to be able to maintain each others trust and obtain and respect their informed consent to data exchanges before they take place. In the rest of this paper, we will refer to these requirements as trust and consent. In the following, we will briefly present the scope of the overall study.

3.3. Scope

Of the many features specified by Gaia-X, trust and consent remain a topic of lively discussion and research, with frequent regulatory changes still occurring, such as the German “Gesundheitsdatennutzungsgesetz” (engl. Health Data Utilization Act (https://www.bundesgesundheitsministerium.de/ministerium/gesetze-und-verordnungen/guv-20-lp/gesundheitsdatennutzungsgesetz.html (accessed on 5 December 2024)) and AI Act (https://www.europarl.europa.eu/topics/en/article/20230601STO93804/eu-ai-act-first-regulation-on-artificial-intelligence (accessed on 5 December 2024)). This, in particular, implies that we should not unify the use cases in terms of what Gaia-X calls data exchange, policies, labels, and data governance, all of which are related to the actual exchange of the data after trust and consent have been established, and specifying data formats and standards for the exchange, access rights afterwards, life cycle management, and more [21]. We chose to keep these aspects outside of the scope of our work, since the individual use cases have little in common in that regard, as some are proprietary and commercial, some are for research, and some are based on open standards like DICOM and HL7 FHIR (https://www.hl7.org/fhir/ (accessed on 5 December 2024)) [22], while some are not. We further do not require any software to be hosted in a centralized location, and we aim to be as decentralized as possible and enable the use cases to make those decisions themselves.

4. Gaia-X

Having presented the use cases’ requirements regarding Gaia-X and the focus of this study, namely trust and consent, we next detail the relevant Gaia-X concepts.

Gaia-X’s mission statement says that it specifies a framework for service-based ecosystems that enables the sharing of data while maintaining trust between involved parties and retaining the users data sovereignty, thus respecting data protection regulations. It does so in a federated manner, rather than a centralized, cloud-like manner [21].

Analyzing this mission statement with respect to the requirements of our use cases, Gaia-X aims to enable our use cases to share data among their stakeholders and maintain the trust between them while doing so. Furthermore, it gives each of them control over their data, including distribution. This is at the core of adhering to many of the strict data protection regulations that the use cases have to respect, and thereby also implies that some form of consent is given before data are exchanged. How this consent is gained has to be determined per use case. In this way, it is possible to fairly well match the requirements of the use cases. To actually achieve this, stakeholders intending to exchange data had to become Gaia-X conformant by adhering to several specification documents [23].

Most notable here were the Gaia-X Architecture Document [24] and the Gaia-X Trust Framework [25]. For the purpose of the implementation, we first “froze” the specifications in a specific state, in order not to have to shoot at a moving target. We then modified, extended, and adapted several concepts after thorough analysis, trying to remain as close as possible to the original specifications, yet also coherent and useful to our study. In the following, we present the concepts as modified and implemented by us and used throughout the Gaia-X-Med project.

4.1. Architecture of a Gaia-X Dataspace

Becoming Gaia-X conformant starts by entering a Gaia-X Federation, which is a collection of Participants aiming to exchange data. Federations serve as the technical and organizational foundation for the associated dataspaces where these exchanges occur. Each federation facilitates individual exchanges, rather than managing the entirety of its dataspaces (see Figure 3). Within this framework, so-called Services act as the enablers of data exchanges, with the requesting party as the Consumer and the responding party as the Provider. These exchanges typically involve digital data but can include physical goods or resources. Before any service is consumed, a Contract must be negotiated, specifying the terms of the data exchange. This contract ensures consent is obtained beforehand. Gaia-X Credentials, which provide certified information about participants issued by trusted Credential issuing entities, help to make this consent “informed”.

The requesting party is the Consumer and the responding party the Provider. To be precise, a service in a digital environment necessarily deals with the exchange of some kind of data, but can also include an exchange of physical goods or the provision of resources. Most of the services relevant for our use cases were completely digital however. As a core concept, before a service can be consumed, often simply meaning that the data in question can be exchanged, a Contract for the consumption has to be negotiated between the consumer and provider. This contract represents the consent of both parties to precisely specified future data exchanges and thereby fits our requirement of obtaining consent before data exchanges take place. Consent is also implicitly respected, since data exchanges can only happen if the corresponding contracts were negotiated previously. To help the consent become informed, Gaia-X presents the concept of Credentials, which are information about participants given out and certified by Credential issuing entities, mostly institutions external to a particular contract. All parties in a contract can then request these entities to verify the information certified by them beforehand, serving as a source of truth about the issues they are negotiating, addressing the need for correctness in agreements, including informed consent.

While the previous concepts are fundamental to Gaia-X, the following are less precisely specified, and were modified and adapted by us.

Addressing the requirement of maintaining trust between data-exchanging parties, participants in a federation are required to obtain a particular kind of credential, certifying their identity and their participation in the federation itself. This credential can then be used in the contract and during the later service consumption. This setup enables mutual trust when combined with the corresponding real legal personal and organization identities checked during the onboarding of participants. To facilitate this, several federation services are conceptualized, enabling participants to enter the federation in the first place and form contracts. Helping to find potential providers to form contracts with, participants can use one such federation service, the Catalog, or service registry, where providers register their services and consumers can browse them. This concept gives rise to the idea of a service ecosystem, where contracts are negotiated in an open, shared marketplace of services. We will present more federation services focused on more technical aspects, as well as several processes from the initial entering of the federation to the forming of the contract to the eventual consumption of the service, in Section 5.

4.2. Trust Inside a Federation

A core motivation for Gaia-X as a European initiative was to do away with the reliance on large non-European cloud providers, who are not inherently subject to European law, particularly its data protection regulations. When talking about trust, this manifests itself mainly in a decentralized approach with many equal parties, and limited managing entities with limited authority or responsibility, as opposed to a few large highly centralized cloud providers. This approach is detailed in the Trust Framework document, an uncharacteristically technical Gaia-X specification, which specifies the involved federation services and even prescribes W3C specifications for several technologies to be used [25].

In the following, we present a small summary of the concepts presented there, which we largely adopted but also modified in some cases.

Trust is managed via two core aspects: identity verification of Participants and Services, and validation of their information (Claims). Verified Claims, represented as Gaia-X Credentials, are certified by trusted third parties called Trust Anchors, who ensure claims like residency or server location claims comply with the relevant regulations. These credentials form a foundational part of the contracts governing data exchanges. The Gaia-X Trust Framework prescribes that these Credentials are to be implemented via the W3C specified Verifiable Credentials standard [26].

For the second main aspect of trust, the verification of the identity of a Participant, Gaia-X employs Decentralized Identifiers (DIDs) [27], issued and certified by a global managing entity during onboarding. This ensures that legal entities or individuals are authentic federation participants. The responsible Gaia-X entity is the Digital Clearing House,which employs Compliance and Registry Services to validate these credentials and maintain a list of Trust Anchors. Multiple clearing houses hosted by different entities ensure redundancy, all monitored by the Gaia-X Association to maintain trust.

Given the complexities of integration with these existing Gaia-X services, the Gaia-X-Med project established its own modified Compliance and Registry Services, leveraging open-source Gaia-X code. This allowed the creation of standalone federations tailored to project needs, enabling participants to exchange data securely, while adhering to strict compliance requirements.

4.3. Addressing Conceptual Shortcomings of Gaia-X

In the following, we present our adaptations of Gaia-X’s concepts to enable individual persons not associated with a single organization, such as patients, to participate in federations, while keeping their data sovereignty. In the Gaia-X specifications, individual persons are considered end-users associated with exactly one organization, as customers or employees, while only organizations can be Participants. This conceptual shortcoming has often been addressed by integrating Personal Data Wallets, possibly even finding its way into the Gaia-X specifications via a “Wallet Task Force” [28]. This would be in accordance with efforts like the Gematik (https://www.gematik.de/ (accessed on 5 December 2024)) and electronic health records in Germany (ePA, s. above) and other countries like Denmark (https://healthcaredenmark.dk/national-strongholds/digitalisation/digital-infrastructure/ (accessed on 5 December 2024)), or Estonia (https://e-estonia.com/solutions/e-health/e-health-records/ (accessed on 5 December 2024)).

To explain our approach in addressing this shortcoming, we briefly present and discuss the options we explored. Figure 4 shows the three different options as flows of data.

In the very common Figure 4a, a researcher or company obtains patient data stored in hospital or doctor’s office information systems, despite patients providing certain medically relevant information only directly, via wearables or questionnaires. Supporting this flow, DICs provide anonymized routine data of multiple patients after ethical approval by the associated hospital of the requester’s stated purpose, which has to be for research. Patients enable DICs to do this by compromising on their data sovereignty via a broad consent agreement. For patients unwilling to compromise, the hospitals and doctor’s offices effectively engage in consent management, acting as custodians of patient data and asking patients directly before sending any data. Forwarding each data request to all previous patients seems organizationally infeasible, given that contacting patients for routine checkups already poses challenges to many medical professionals. Furthermore, interested researchers or companies will have to contact many institutions to form a coherent dataset, since individual patients can visit many hospitals and doctor’s offices, change insurance companies, move cities, etc.

Figure 4b aims to remedy these problems by first contacting patients directly and obtaining their authorization to access the relevant, agreed-upon parts of the data they would be able to access at all involved institutions, thus keeping the patient fully in control of the data, even without requiring resources to store the data themselves. We therefore consider this approach as matching Gaia-X very well and advocate for its inclusion. However, when integrated via patients effectively becoming trust anchors and certifying access rights for the requesters, this does not fully solve the problem, since patients themselves can also be a source of data.

Lastly, Figure 4c addresses this last point and is the approach we decided to employ. Patients here are regarded as the single source of their data from the point of view of interested researchers and companies. The latter simply contact the patients directly, who then decide which data to request from its origin and to distribute to a requester. This is the most straightforward version of data sovereignty and to implement it via Gaia-X, we decided to map individual persons, thus patients, onto the Participant concept. They can go through onboarding, negotiate contracts, and even provide services, if necessary. In this way, they retain full data sovereignty.

Patients can still proactively offer data to interested researchers and companies, even by integrating institutions like DICs as Participants, whose value for patient acceptance is not to be underestimated, due to their association with the hospital and their rigid use of anonymization. All agreements, like broad consent or even ethical approvals, could be made within Gaia-X, even for similar institutions with a commercial focus, or only parts thereof, like registers for certain groups of patients or anonymizing services.

5. Gaia-X-Med: Our Solutions

In this section, we present our implementation of the concepts described above.

5.1. Web-Based Approach and the Yo-Ga-X Framework

The existing frameworks described above are all based on asynchronous, commonly used web technology. We consider our approach as going even further in that direction.

While, as described above, mapping patients to the concept Participant is very helpful, it also represents a higher technological burden for them than for organizations. We therefore made all processes in which a Participant interacts with our federation services as accessible as possible and encourage all providers in the federation to do the same with their services. This accessibility manifests itself by not using a connector component that has to be configured and programmed, but rather services offering a web page interface structured to guide users through the process.

This might even turn out to be a valuable approach to alleviate some of the resource scaling problems on the consumer side that certain connector-based approaches face, since an interaction initiated by a consumer is handled almost entirely in the browser and leaves virtually no resource footprint on their side after the interaction.

All our code is available open-source as a framework called Your Own Gaia-X (Yo-Ga-X) (https://docs.gaia-med.org (accessed on 5 December 2024)). It includes all components necessary to set up a standalone federation based on our modified Gaia-X concepts. Yo-Ga-X as a framework is lightweight, since every component is kept simple and thus easy to extend or even replace. It is also easy to set up, as each component can be set up locally or deployed independently and setup guides and introductory examples are provided. It includes all used federation service components, as well as a general demonstrator using an example service consumption of a Consumer at a Provider’s service, with detailed documentation. We present the most important features of the framework in the following subsection.

5.2. The Four Main Processes

To reduce the complexity of the overall process, the Yo-Ga-X framework defines the following four sub-processes (see Figure 5), each only focusing on a few involved Participants and Federation Services:

• Participant Onboarding, where both Providers and Consumers initially provide information about themselves and join the Gaia-X-based federation, which is the basis for the Yo-Ga-X-powered service ecosystem,
• Service Onboarding, where Providers register their offered Service in the federation’s Catalog,
• Service Discovery and Contract Negotiation, where Consumers browse the Catalog to find Services they are interested in and initiate the negotiation of a Contract with the Provider of a chosen Service,
• Service Consumption, where consumers finally consume the Service they negotiated a Contract for, including the authentication at the Provider.

In the following, we present these processes in further detail.

During Participant Onboarding, all Participants—Consumers as well as Providers—first create a credential containing identifying details about themselves and their legal person which they wish to share with other Participants. The federation’s Compliance Service then validates the credential’s structure and certifies it as being part of the federation. Finally, the Participant receives a Participant Identity File, representing his participation in the federation, while simultaneously acting as the passkey for authentication.

During Service Onboarding, Providers first create a credential containing details about the particular Service they intend to provide and certify that they are the Participant responsible for its management. Again, the Compliance Service validates the credential’s structure and certifies the Service as being part of the federation and that it belongs to the Provider. Finally, the Provider registers the Service in the Catalog, another Federation Service, where it can be discovered by potential Consumers.

During Service Discovery, Consumers first authenticate themselves in the Catalog as a Participant of the federation. They are able to browse it and choose a Service they intend to consume. This choice then initiates the Contract Negotiation process, during which the Negotiation Service, yet another Federation Service, corresponds with the soon-to-be Consumer and the Provider of the Service to form a Contract expressing the informed consent of both parties to the future service consumption.

During the actual Service Consumption, Consumers attempt to authenticate themselves at the Provider’s Service using their Participant Identity File, containing their certificate of participation in the federation. Since this identifying certificate is also part of the Contract the Provider received during the Contract Negotiation process, the Provider can verify the requesting party’s identity and provide the Service according to the negotiated conditions.

Having presented the four main processes and how they fit together, we next present how we implemented the systems that enable them.

5.3. Identity and Its Problems

In order to establish a solid basis for trust in a federation, Gaia-X prescribes the use of Decentralized Identifiers (DIDs), as previously mentioned [27]. As we will see in detail in the following, these identifiers are used widely throughout the federation, for example in Credentials and thus Contracts. As a trust-enabling mechanism, they can be verified, clarifying which legal person taking part in the federation is behind the identifier.

To implement DIDs, basically, two main approaches are available, namely blockchain and the web domain approach As per the W3C DID specification, in both approaches, the controller of a DID, which here is also its subject, specifies the method of verification of the DID and, for practical reasons, ensures the facilities to go through with it are in place [27]. In the blockchain approach, the DID controller and subject take part in a distributed ledger storing all the data, possibly utilizing cryptographic wallets. To sufficiently enable trust and acceptance among participants, however, the specific choice of distributed ledger or blockchain is pivotal, ranging from individual to federation-wide to European to global distribution, and from commercially-focused crypto currencies like Ethereum (https://ethereum.org/en/ (accessed on 5 December 2024)) to ones supported by official European institutions like electronic IDentification, Authentication and trust Services (eIDAS) (https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation (accessed on 5 December 2024)), European Blockchain Services Infrastructure (EBSI) (https://ec.europa.eu/digital-building-blocks/sites/display/EBSI/What+is+EBSI (accessed on 5 December 2024)), or the European Self-Sovereign Identity Framework (ESSIF) (https://essif-lab.eu/ (accessed on 5 December 2024)), aligning more with Gaia-X as a European initiative. While seemingly feasible, we ultimately decided against this approach, since we determined its integration with the Gaia-X concepts as adapted by us to be too resource-intensive a task for a problem of medium importance. However, due to its potential for solving similar problems encountered by other projects in the health domain and beyond, we encourage the pursuit of this approach by Gaia-X itself, including its conceptual integration as a technology into the specifications, alongside our adaptations if needed, and its implementation via XFSC, for example.

While potentially useful, the blockchain approach is not without problems, even being mentioned in the abstract of the specifications of the did:web Method [29], the core technology of the alternative web domain approach. As stated there, DIDs that target a distributed ledger often do not become adopted on mass due to not accumulating enough meaningful trusted data around the associated identities. Despite likely being remedied once the mentioned official institutions are involved, this remains true, at least for federation-wide ledgers. Representing an alternative, the web domain approach uses the did:web Method and prescribes the DID controller, and in this case also the subject, as the domain directly associated with the participant behind the identifier. Verifying an identifier in this case then amounts to checking whether the correct domain is at the other end of the communication. Whether this association of participant and domain is a sufficient basis for trust depends then on the reliability of the employed Domain Name System (DNS) and the verifiability of a domain name to the legal person, the organization, or the individual behind the domain. While a feasible approach for organizations with sufficient technical capabilities, such as web servers to host the systems and possession of unchanging, unique, verifiable domains, this incurs a significant technological burden for the average individual person, who typically interacts with the Internet via unnamed, dynamically changing IP addresses and who do not run servers.

Despite not fully addressing the requirements of typical medical use cases, we compromised on this second approach due to the first being to resource-intensive to integrate for too little gain. Nevertheless, we underline the tremendous potential of the blockchain approach for solving challenges common to the health domain as a whole and beyond.

In the following, we present the systems at the core of our implementation that enable the presented four main processes based on the web domain approach. In doing so, we contrast it specifically to the unmodified, conventional Gaia-X concepts and their implementations like XFSC/GXFS and EDC.

5.4. Authentication

In a typical Gaia-X dataspace, organizations are identified through signed Gaia-X Credentials that establish their trustworthiness. However, it is their employees, not the organizations directly, who act within the dataspace. To facilitate this, the Gaia-X architecture enables organizations to issue Principal credentials to employees, linking back to the organization’s Gaia-X Credential. This is implemented through two key components: the Organization Credential Manager (OCM) and the Personal Credential Manager (PCM), a smartphone app allowing users access to a blockchain-based wallet containing their credentials.

While technically sound, the current Gaia-X implementation does not adequately address scenarios where patients act as Participants, who often cannot be tied to a single organization. To overcome this limitation, we modified the Gaia-X framework to integrate patients directly as Participants. Our solution simplifies authentication by utilizing Gaia-X Credentials as authentication tokens, uniquely identified through W3C Decentralized Identifiers and stored in self-hosted wallets alongside keyfiles obtained during onboarding.

5.4.1. Onboarding

The process of obtaining Gaia-X Credentials involves multiple steps, including interactions with Trust Framework services like the Compliance Service and the creation and signing of W3C Verifiable Credentials. To simplify this, we developed the Credential Manager, a web application that streamlines this process by gathering claim data through a user-friendly form and automating API calls, credential creation, and signing.

Gaia-X stipulates that credentials must be hosted in a decentralized manner on one’s own infrastructure (wallets), achieved through W3C Decentralized Identifiers (DIDs) encoded as DID URLs, which encode the real storage location. Out of several options, our implementation adopts the did-web method, which uses HTTPS and DNS to establish domain-based trust, linking credential storage to domain ownership [29].

The Credential Manager integrates with a simple, self-hostable Credential Store based on nginx, enabling users to store credentials securely. It also generates essential documents: a DID document with a public key and a link to the Gaia-X Credentials, uploaded to the Participant’s wallet, and a Participant Identity File containing the private key and the keypair’s DID URL, encrypted and downloadable for the user.

5.4.2. Authentication

Participants initiate authentication by creating a JSON Web Token (JWT) for login, containing their DID URL, signed with the private key from their Participant Identity File. This token is sent to the verifying party, such as a Provider Service. By resolving the DID URL to an HTTPS address, the verifier downloads the DID Document containing the public key to validate the token’s signature.

The verifier then follows the link in the DID Document to access the Participant’s Gaia-X Credential, ensuring it meets the Gaia-X Trust Framework’s rules. If both the token and Credential are valid, the verifier can trust the Participant’s identity and claims.

The Gaia-X-Med implementation simplifies this process with a federation-wide Authentication Service. This service validates login tokens, verifies compliance, and returns trustworthy Credentials, sparing Providers from implementing the entire verification process independently. Figure 6 shows a simplified overview of the process.

As for integrating this authentication flow into the backend architecture of a Provider Service, we developed two methods, each covering a different use case. The first combines the authentication flow with OpenID Connect, a widely used standard for enabling single sign-on authentication [30].

To realize this, an OpenID Connect Identity Provider based on node-oidc-provider (https://github.com/panva/node-oidc-provider (accessed on 5 December 2024)) was developed and hosted as a federation-wide web application. After asking the user for their Participant Identity File and decryption passphrase, the application generates a Login token client-side that is then sent to the Authentication Service. The returned Participant Credential is mapped to the corresponding OAuth2 claims, which are finally forwarded to the Provider Service.

The Provider can use any of the various available OpenID Connect clients to enable this authentication method; popular choices include Keycloak (https://www.keycloak.org (accessed on 5 December 2024)) and proxy server modules like mod_auth_openidc (https://github.com/OpenIDC/mod_auth_openidc (accessed on 5 December 2024)) for use with the Apache HTTP Server (https://httpd.apache.org/ (accessed on 5 December 2024)).

The OpenID Connect method is particularly suited for easily integrating interactive Gaia-X-Med authentication for web-application-based services. Figure 7 shows a schematic overview of the OpenID Connect method.

The other method is what we dubbed the Proxy method. Here, we developed a middleware solution called the Authentication Proxy, which is deployed in front of a Provider Service and intercepts incoming requests from Consumers. Before allowing requests to reach the Service, Consumers are required to register an authenticated session with the Authentication Proxy using a Login token. To allow simple interfacing using this method, we have provided clients written in Python and TypeScript that implement the necessary communication protocol with the Authentication Proxy transparently; from a developer’s point of view, after instantiating a client using their Participant Identity File and decryption passphrase, this provides a simple HTTP request API that automatically registers a session and uses it to make authenticated requests.

The Proxy method was developed as a very simple, plug-and-play solution for enabling automated requests to API-based Provider Services, as it does not require human interaction, as opposed to the OpenID Connect method (see Figure 8).

5.5. Contract Negotiation

XFSC [19] enables authorization through a Policy Engine that, once deployed and configured, allows Providers to set certain rules to handle incoming requests from Consumers. We have decided to approach the topic of authorization by using digital contracts as a base. Contracts are only briefly touched upon in the Gaia-X architecture itself; stating that while they form an important part of the ecosystem, their implementation details are outside of scope of the architecture [24].

We had three initial requirements for our digital contracts: they should be machine readable, able to be digitally signed by involved Participants, and tamper-proof. We found that the W3C Verifiable Credentials standard, which was already being used in the project for enabling Gaia-X Credentials, fulfilled all of these requirements:

• they are formatted as JSON-LD and are furthermore validated against schemata, so they are machine readable;
• they can be digitally signed with cryptographic keys, which also effectively renders them immutable;
• additionally, they can be bundled by anyone into Verifiable Presentations, which can also be signed individually from the Verifiable Credentials within. This provides an excellent method for allowing a neutral third party to “notarize” a collection of Credentials.

A Gaia-X-Med Contract passes through four steps, as shown in Figure 9. The content of a Contract comprises two parts; first, a static, free-form (non-machine readable) non-negotiable text part which the Consumer has to agree to. The other part is defined through the Contract Template, which is a JSON Schema (https://json-schema.org/ (accessed on 5 December 2024)) object embedded inside a Service Offering’s Credential. Through the Contract Template, a Provider can offer configurable parameters for the Service to the Consumer, which allows them to negotiate certain aspects of the Contract. For example, a web hosting service could have a configurable amount of data storage.

When visiting the Catalog web application and picking the “Negotiate contract” option for a Service they wish to consume, the Consumer user is presented with the Service’s Contract Template rendered into a form, as well as the static contract terms to which they have to give their explicit agreement. The data from the submitted form are bundled and signed into a Contract Offer (as a Verifiable Credential) and sent to the federation-wide Negotiation Service, which acts as a notary between the Consumer and the Provider. It creates a Verifiable Presentation containing the Consumer’s Contract Offer and adds its own signature, creating the Notarized Contract Offer, which it then forwards to the Provider. At the Provider’s end, a service called the Contract Service listens for incoming Notarized Contract Offers from any whitelisted Negotiation Service. Once an offer arrives, it too performs some routine checks including re-confirming the authenticity of the Consumer making the offer and validating that the offer aligns with the Contract Template. It then forms a response to the offer. By default, all valid offers from valid Participants are accepted; however, a Provider is also able to extend the Contract Service’s negotiation routine with programmatic rules which, based on the Consumer’s identity and the content of the offer, result in one of two additional outcomes:

• The offer is denied—for example, a Provider can make the decision to not accept offers coming from Consumers having a certain Claim; e.g., restricting the Service to only Consumers from research organizations.
• The offer is accepted under modified conditions—if the Provider is willing to form a contract but not under the conditions specified by this Consumer. In this case, the Contract Service is capable of responding with an adjusted counteroffer that the Consumer can choose to accept instead.

In case the Contract Service accepts the offer, it proceeds to respond with a Contract Offer of its own, carrying the same contents and signed using the Provider’s identity. The Negotiation Service finally bundles the Contract Offers from both parties into a signed Verifiable Presentation. Since the Presentation is signed by the Negotiation Service’s private key, none of the contained Credentials can be modified or replaced without breaking the signature verification, making it effectively immutable. The finalized Contract is forwarded to both Consumer and Provider. On the Provider side, it is stored inside a database and can then be used to authorize Consumers—after receiving a request, the Provider Service backend is required to check whether a currently valid Contract exists for this Consumer, and if there is none, the request is denied.

6. Evaluation/Lessons Learned

This section evaluates the Gaia-X-Med implementation’s applicability to the six eHealth use cases, providing insights into its effectiveness and limitations. The diverse requirements of these use cases offer a comprehensive view of Gaia-X’s suitability for healthcare applications.

Technically, all use cases successfully utilized the Yo-Ga-X framework to establish participants, onboard them to a common federation, and leverage federation services for compliance and contract negotiation. A shared federation approach was adopted to test the Gaia-X service ecosystem’s viability. However, cross-use-case service sharing was limited, suggesting that broader and more thematically aligned use cases would better showcase the potential of shared services. The single Trust Anchor implemented posed challenges, as identifying credible certifying institutions remains complex. Often, the participants themselves were the most reliable information sources, diminishing the value of external certification.

Use cases focusing on business-to-business (B2B) scenarios with well-established organizations demonstrated the framework’s strengths in maintaining trust and consent. Conversely, use cases involving individual participants, such as patients, faced technological barriers that hindered full federation integration. This shortcoming highlights the need for conceptual adjustments to Gaia-X’s approach, as patients lack organizational affiliations similar to those of employees or customers, complicating their role as participants. We hope to further contribute to these efforts in the future, as many projects, not just from the health domain, are doing.

While trust and consent were central, other Gaia-X features, such as data exchange, policies, and labels, warrant greater focus. Efforts to unify Gaia-X implementations like XFSC, EDC, and Yo-Ga-X into interoperable federations could enhance cross-domain applicability. Institutional aspects, such as trust anchors and clearinghouses, also require attention, to ensure robust and scalable dataspaces.

7. Conclusions and Future Work

Data sovereignty, security, and interoperability remain pivotal for a European digital infrastructure, particularly in regulated domains such as healthcare. The Gaia-X-Med project aimed to test the applicability of Gaia-X concepts to address these challenges, focusing on trust and consent. The project leveraged the open-source Yo-Ga-X framework to implement Gaia-X principles across six diverse eHealth use cases, each representing unique requirements for secure and compliant data sharing.

The results demonstrated that the Gaia-X concepts are effective in business-to-business contexts, where trust can be established through organizational credentials. However, when involving individual patients, the existing Gaia-X framework encountered limitations. Patients, often unaligned with any organization, face technological burdens in participating directly in federations, indicating a need for further conceptual evolution of Gaia-X to support independent data contributors.

To address the identified limitations, future work should focus on extending Gaia-X to better accommodate individual data contributors such as patients. The integration of personal data wallets or similar technologies would empower individuals to manage their data directly, ensuring compliance with privacy regulations, while maintaining full sovereignty. This shift would require additional Gaia-X conceptual modifications, such as treating individuals as standalone participants in federations, with tailored onboarding and credentialing processes that reduce technological barriers.

Furthermore, regulatory enhancements could significantly improve Gaia-X’s scalability and utility. Establishing standardized trust anchors and clearinghouses would enhance the verification of credentials and governance of federations, fostering trust among participants. Similarly, incorporating policies to enforce federation-wide constraints on data exchange, including post-consumption lifecycle management, would bolster data security and compliance.

Interoperability across Gaia-X implementations, such as XFSC, EDC, and Yo-Ga-X, should also be prioritized. Unified frameworks and shared standards would enable seamless collaboration across domains, realizing Gaia-X’s vision of interoperable, federated ecosystems. Finally, traceability mechanisms, such as immutable contract and service consumption records maintained by neutral entities, could address inconsistencies and support conflict resolution.

Broadly, future efforts should consider the global landscape, learning from less regulated but more user-friendly approaches in other regions. Combining stringent European data protection standards with practical usability enhancements would make Gaia-X a robust model for secure and sovereign data ecosystems, particularly in sensitive domains like healthcare.