2.8
8.3
Article
Gaia-X-Med: Experiences with
Building Dataspaces for Medical
Applications
Bennet Gerlach, Hannes Hesse, Stefan Fischer and Martin Leucker
https://doi.org/10.3390/fi16120463
Article
Gaia-X-Med: Experiences with Building Dataspaces for
Medical Applications
Bennet Gerlach 1,† , Hannes Hesse 2,† , Stefan Fischer 1, *
1
2
3
*
†
and Martin Leucker 2,3
Institute of Telematics, University of Lübeck, 23562 Lübeck, Germany; be.gerlach@uni-luebeck.de
Unitransferklinik Lübeck, 23562 Lübeck, Germany; hhesse@unitransferklinik.de (H.H.);
martin.leucker@uni-luebeck.de (M.L.)
Institute of Software Engineering and Programming Languages, University of Lübeck, 23562 Lübeck, Germany
Correspondence: stefan.fischer@uni-luebeck.de; Tel.: +49-451-3101-6400
These authors contributed equally to this work.
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.
Keywords: Gaia-X; data sovereignty; federated ecosystems; sovereign data infrastructure; secure
authentication; digital contract negotiation; medical and healthcare applications
Citation: Gerlach, B.; Hesse, H.;
Fischer, S.; Leucker, M. Gaia-X-Med:
Experiences with Building Dataspaces
for Medical Applications. Future
Internet 2024, 16, 463. https://
doi.org/10.3390/fi16120463
Academic Editor: Francesco
Buccafurri
Received: 15 October 2024
Revised: 30 November 2024
Accepted: 6 December 2024
Published: 9 December 2024
Copyright: © 2024 by the authors.
Licensee MDPI, Basel, Switzerland.
This article is an open access article
distributed under the terms and
conditions of the Creative Commons
Attribution (CC BY) license (https://
creativecommons.org/licenses/by/
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
4.0/).
Future Internet 2024, 16, 463. https://doi.org/10.3390/fi16120463
https://www.mdpi.com/journal/futureinternet
Future Internet 2024, 16, 463
2 of 21
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 GaiaX 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–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
Future Internet 2024, 16, 463
3 of 21
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 GAIAX 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 farreaching 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
Future Internet 2024, 16, 463
4 of 21
(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
Future Internet 2024, 16, 463
5 of 21
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.
Future Internet 2024, 16, 463
6 of 21
Figure 1. A diagram showing the six use cases of the Gaia-X-Med project, with one color each. The
top row shows the sources of data, the middle their kind, and the bottom their usage.
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):
Figure 2. A diagram showing stakeholders in the Gaia-X-Med project, their intentions, and agreements between them, which facilitate their interaction, while adhering to data security rights. The
colors and numbers correspond to Figure 1.
•
•
•
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.
Future Internet 2024, 16, 463
7 of 21
•
•
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-regulationon-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
Future Internet 2024, 16, 463
8 of 21
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”.
Figure 3. Diagram showing the interactions between the different entities in a Gaia-X dataspace and
the resulting processes. Providers provide Services to Consumers, which they can find via a Catalog.
Consumers consume the service after negotiating a contract for its usage with its Provider, which
contains Credentials for relevant information.
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
Future Internet 2024, 16, 463
9 of 21
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, GaiaX 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-XMed project established its own modified Compliance and Registry Services, leveraging
Future Internet 2024, 16, 463
10 of 21
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.
Figure 4. Diagram showing three different flows (a–c) of patient data from hospitals, doctor’s offices,
insurance companies, as well as patients themselves, to interested researchers and companies, while
keeping the patient in control.
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
Future Internet 2024, 16, 463
11 of 21
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.
Future Internet 2024, 16, 463
12 of 21
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.
Figure 5. Four diagrams showing each of the four main processes in detail. First, a participant is
onboarded, then their service is onboarded, next the service is discovered by another participant and
both negotiate a contract for its usage, so that finally the service can be consumed.
Future Internet 2024, 16, 463
13 of 21
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 tech-
Future Internet 2024, 16, 463
14 of 21
nology 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 GaiaX 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
Future Internet 2024, 16, 463
15 of 21
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.
Figure 6. A simplified overview of the Gaia-X-Med authentication flow. A Consumer submits a locally
signed Login token to the Authentication Layer, which forwards it to the Authentication Service.
After fetching and verifying the Consumer’s identity and checking their Compliance Credential
signature, the Authentication Service responds with the now-verified Credentials, which can then be
trusted and used further by the Provider.
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.
Future Internet 2024, 16, 463
16 of 21
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.
Figure 7. An overview of the OpenID Connect authentication method. A compatible OpenID Connect
Client is deployed by a Provider in front of the Service, which redirects the user to the OpenID Connect
Identity Provider and forwards the resulting OAuth2 credentials to the Service backend.
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).
Figure 8. An overview of the Proxy authentication method. The Authentication Proxy is deployed as
a middleware by a Provider in front of their Service. It transparently handles authentication and only
lets requests with a valid session pass.
Future Internet 2024, 16, 463
17 of 21
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) nonnegotiable 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.
Figure 9. How a Contract is formed in four steps. The signed terms and identities of both Consumer
and Provider, as Verifiable Credentials, as well as a Negotiation Credential containing negotiation
metadata, are bundled by the federation-wide Negotiation Service into a Verifiable Presentation,
which is signed as a whole, resulting in the finalized Contract.
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
Future Internet 2024, 16, 463
18 of 21
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
Future Internet 2024, 16, 463
19 of 21
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-GaX, 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.
Author Contributions: Conceptualization, all authors; methodology, all authors; software, B.G. and
H.H.; validation, B.G. and H.H.; investigation, B.G. and H.H.; writing—original draft preparation,
B.G. and H.H.; writing—review and editing, S.F. and M.L.; visualization, B.G. and H.H.; supervision,
S.F. and M.L.; project administration, S.F. and M.L.; funding acquisition, S.F. and M.L. The authors
used generative AI to make some of the descriptions more concise and streamlined. All authors have
read and agreed to the published version of the manuscript.
Funding: This research was funded by the German State of Schleswig-Holstein, within the funding
framework “Künstliche Intelligenz”.
Data Availability Statement: The original contributions presented in the study are included in the
article, further inquiries can be directed to the corresponding author.
Future Internet 2024, 16, 463
20 of 21
Acknowledgments: The authors wish to thank Dirk Schrödter from the government of SchleswigHolstein for continuous support of their activities in investigating AI applications in the healthcare
domain, their colleagues in the other work packages of Gaia-X-Med for commenting on the solutions
developed, and Raimund Mildner for being a continuous source of inspiration.
Conflicts of Interest: Hannes Hesse is an employee of the company Unitransferklinik GmbH. The
authors declare no conflicts of interest.
References
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
Lohmöller, J.; Pennekamp, J.; Matzutt, R.; Wehrle, K. On the need for strong sovereignty in data ecosystems. In Proceedings of the
DEco@ VLDB, Sydney, Australia, 5 September 2022; pp. 51–63.
Jussen, I.; Möller, F.; Schweihoff, J.; Gieß, A.; Giussani, G.; Otto, B. Issues in inter-organizational data sharing: Findings from
practice and research challenges. Data Knowl. Eng. 2024, 150, 102280. [CrossRef]
Deshmukh, R.A.; Collarana, D.; Gelhaar, J.; Theissen-Lipp, J.; Lange, C.; Arnold, B.T.; Curry, E.; Decker, S. Challenges and
Opportunities for Enabling the Next Generation of Cross-Domain Dataspaces. In Proceedings of the Second International
Workshop on Semantics in Dataspaces, Co-Located with the Extended Semantic Web Conference, Hersonissos, Greece, 26–27
May 2024.
Hellmeier, M.; Pampus, J.; Qarawlus, H.; Howar, F. Implementing data sovereignty: Requirements & challenges from practice.
In Proceedings of the 18th International Conference on Availability, Reliability and Security, Benevento, Italy, 29 August–1
September 2023; pp. 1–9.
Otto, B.; ten Hompel, M.; Wrobel, S. Designing Data Spaces: The Ecosystem Approach to Competitive Advantage; Springer Nature:
Berlin/Heidelberg, Germany, 2022.
Lang, S.; Kneuper, R. Datenschutz und Informationssicherheit in Gaia-X. Datenschutz Und-Datensicherheit-Dud 2022, 46, 778–781.
[CrossRef]
Otto, B.; Jarke, M. Designing a multi-sided data platform: Findings from the International Data Spaces case. Electron. Mark. 2019,
29, 561–580. [CrossRef]
Pampus, J.; Jahnke, B.F.; Quensel, R. Evolving data space technologies: Lessons learned from an IDS connector reference
implementation. In Proceedings of the International Symposium on Leveraging Applications of Formal Methods, Rhodes, Greece,
22–30 October 2022; Springer: Berlin/Heidelberg, Germany, 2022; pp. 366–381.
Mügge, J.; Grosse Erdmann, J.; Riedelsheimer, T.; Manoury, M.M.; Smolka, S.O.; Wichmann, S.; Lindow, K. Empowering end-oflife vehicle decision making with cross-company data exchange and data sovereignty via Catena-X. Sustainability 2023, 15, 7187.
[CrossRef]
Lopes, P.M.; Guimarães, P.; Pereira, T.F.; Machado, R.J. Gaia-X & Fiware: Implementation of a Federated Data Platform in Smart
Cities. Procedia Comput. Sci. 2024, 239, 1506–1515.
Bosse, S.; Berns, K.; Bosch, J.; Dörr, J.; Eichhorn, F.C.; Eisert, P.; Fischer, C.; Gassen, E.; Gerstenberger, M.; Gerighausen, H.; et al.
Nachhaltige Landwirtschaft mittels Künstlicher Intelligenz—Ein plattformbasierter Ansatz für Forschung und Industrie. In Proceedings of the 43. GIL-Jahrestagung, Resiliente Agri-Food-Systeme, Osnabrück, Germany, 13–14 February 2023; Gesellschaft für
Informatik e.V.: Bonn, Germany, 2023; pp. 41–52.
Maia, M.; Jaberansary, M.; Ucer, Y.; Beyan, O.; Kirsten, T. Providing Publicly Available Medical Data Access Under FAIR Principles
for Distributed Analysis. Available online: https://www.egms.de/static/en/meetings/gmds2022/22gmds071.shtml (accessed
on 5 December 2024).
Büchel, J.; Engels, B. Branchentrends beim Data Sharing: Status quo und Use Cases in Deutschland; Technical Report, IW-Repor.
Available online: https://www.iwkoeln.de/studien/jan-buechel-barbara-engels-status-quo-und-use-cases-in-deutschland.html
(accessed on 5 December 2024).
Boll, S.; Meyer, J. Health-X dataLOFT: A sovereign federated cloud for personalized health care services. IEEE MultiMedia 2022,
29, 136–140. [CrossRef]
Meier, J.J.; Hermsen, K.; Bauer, J.; Eskofier, B.M. Digital Responsibility Goals–A Framework for a Human-Centered Sustainable
Digital Economy with a Focus on Trusted Digital Solutions. In dHealth 2022; IOS Press: Amsterdam, The Netherlands, 2022;
pp. 250–259.
Kari, A.; Schurig, T.; Gersch, M. European Health Data Space (EHDS), Gaia-X and Health-X dataLOFT. 2023. Available online:
http://dx.doi.org/10.17169/refubium-41224 (accessed on 5 December 2024).
Toma, M.; Bönisch, C.; Löhnhardt, B.; Kelm, M.; Bohnenberger, H.; Winkelmann, S.; Ströbel, P.; Kesztyüs, T. Research collaboration
data platform ensuring general data protection. Sci. Rep. 2024, 14, 11887. [CrossRef]
Arshad, K.; Ardalan, S.; Schreiweis, B.; Bergh, B. Leveraging Clinical Data Treasures: Integration of an AI Platform into Clinical IT.
In Digital Health and Informatics Innovations for Sustainable Health Care Systems; IOS Press: Amsterdam, The Netherlands, 2024;
pp. 1169–1173.
Eclipse Foundation. Eclipse XFSC (Cross Federation Services Components). 2024. Available online: https://projects.eclipse.org/
projects/technology.xfsc (accessed on 30 September 2024).
Future Internet 2024, 16, 463
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
21 of 21
Eclipse Foundation. Eclipse Dataspace Components. 2024. Available online: https://projects.eclipse.org/projects/technology.edc
(accessed on 30 September 2024).
Gaia-X Association. About Gaia-X-Gaia-X: A Federated Secure Data Infrastructure. 2024. Available online: http://docs.gaia-x.
eu/technical-committee/data-exchange/22.10/dewg/ (accessed on 30 September 2024).
Ayaz, M.; Pasha, M.F.; Alzahrani, M.Y.; Budiarto, R.; Stiawan, D. The Fast Health Interoperability Resources (FHIR) Standard:
Systematic Literature Review of Implementations, Applications, Challenges and Opportunities. JMIR. Med. Inform. 2021, 9, e21929.
[CrossRef]
Gaia-X Association. Gaia-X Framework. 2024. Available online: https://docs.gaia-x.eu/framework/ (accessed on 30 September 2024).
Gaia-X Association. Gaia-X Architecture Document—22.04 Release. 2022. Available online: https://docs.gaia-x.eu/technicalcommittee/architecture-document/22.04/ (accessed on 30 September 2024).
Gaia-X Association. Gaia-X Trust Framework—22.04 Release. 2022. Available online: https://docs.gaia-x.eu/policy-rulescommittee/trust-framework/22.04/ (accessed on 30 September 2024).
Sporny, M.; Longley, D.; Chadwick, D. Verifiable Credentials Data Model v1.1. W3C. 2022. Available online: https://www.w3
.org/TR/vc-data-model/ (accessed on 30 September 2024).
Sporny, M.; Longley, D.; Sabadello, M.; Reed, D.; Steele, O.; Allen, C. Decentralized Identifiers (DIDs) v1.0. W3C. 2022. Available
online: https://www.w3.org/TR/did-core/ (accessed on 30 September 2024).
acatech. Herausforderungen und Lösungsansätze der Gaia-X Förderprojekte (Section 2.3). 2023. Available online: https:
//gaia-x-hub.de/wp-content/uploads/2023/04/WP-Stand-Foerdervorhaben-Gaia-X.pdf (accessed on 30 September 2024).
Gribneau, C.; Prorock, M.; Steele, O.; Terbu, O.; Xu, M.; Zagidulin, D. did:web Method Specification. W3C Credentials Community
Group. 2024. Available online: https://w3c-ccg.github.io/did-method-web/ (accessed on 30 September 2024).
OpenID Foundation. How OpenID Connect Works. 2024. Available online: https://openid.net/developers/how-connect-works/
(accessed on 30 September 2024).
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual
author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to
people or property resulting from any ideas, methods, instructions or products referred to in the content.