Flemish Health Data Space Implementation: Technical Overview and Challenges

Abstract

This paper presents the implementation of a Health Data Space in Flanders, Belgium. The project integrated the fundamental components of a data space while also catering to specific customer requirements. The project utilizes the Eclipse Dataspace Components (EDC) implementation of the Dataspace Protocol, Keycloak as an Identity Provider, and DataHub as the intermediary Metadata Broker to allow data discovery within a data space or across data spaces. In addition, a Clearing House was developed based on customer requirements. The paper presents a state-of-the-art implementation of a data space and provides valuable information on the application of data space concepts within the health sector. It also presents a study of current Electronic Health Records (EHR) data models for semantic interoperability and machine-to-machine data discovery, addressing the data discovery challenge.

Keywords

• eol>Data Space
• Data Discovery
• Linked Data
• Eclipse Dataspace Components (EDC)
• Clearing House

1. Introduction

In February 2020, the European Commission1 published ‘A European Strategy for Data’ [ 1 ] (referred to in this article as ‘EU data strategy’), as part of a wider drive concerning digital transformation and policy [ 2 ]. The EU data strategy creates diferent rules and institutions that seek to improve and facilitate data access and enhance data utilization [ 3 ]. In response to the call for an EU data strategy, the initiative to build Common European Data Spaces has emerged [ 4 ]. The first objective mentioned in the European data strategy is to improve healthcare and promote interoperability within the health sector in Europe [ 3 ]. In May 2022, the European Commission presented its proposal to set up a European Health Data Space (EHDS) aiming to unleash the full potential of health data [ 5 ]. In alignment with European initiatives, the Flemish Health Data Space (referred to in this article as ‘Health Data Space’) project was started.

Within the Health Data Space project [ 6 ], the Business Intelligence (BI) and Data ofice of the Flemish Department of Care and imec collaborated to shape the future of data-driven health policy. Our focus is on investigating the technical, ethical, data processing, and legal prerequisites necessary to establish a data space dedicated to health policy.

This paper aims to demonstrate how data space components can be implemented within the health sector. The technical implementation of the components within the data space aligns with those identified by IDS Reference Architecture Model (RAM) 4.0 [ 7 ] published by the International Data Spaces Association (IDSA). RAM 4.0 outlines the framework for how a data space should be structured from a component perspective, organized into five layers (Business, Functional, Information, Process, and System) and three horizontal aspects (Security, Certification, and Governance).

The technical solutions implemented in the Health Data Space are highlighted in orange in Figure 1 below. Each component will be elaborated upon in the subsequent sections.

2. Dataspace Connector

Numerous data space connectors [ 9 ] are currently being developed, and an overview can be found in the Data Spaces Radar [ 10 ]. When selecting a connector, the primary considerations from the Health Data Space perspective include the following.

• Interoperability: The connector’s ability to work seamlessly with other connectors. • Extensibility: The potential for customization and enhancement of the connector. • Community Support and Active Development: The availability of resources and ongoing improvements.

The Dataspace Protocol (DSP) is the specification that standardizes communication among connectors for data transfer and negotiations [ 11 ]. The Eclipse Dataspace Components (EDC) provide a framework for sovereign [ 12 ], inter-organizational data sharing [ 13, 14 ]. They implement DSP and the relevant protocols associated with GAIA-X [ 15, 16 ].

Additionally, the EDC connector features a modular architecture that supports the integration of extensions. The EDC provides examples and documentation to assist developers in building these extensions, ensuring that the project can be tailored to meet customer needs. Furthermore, it is in continuous development and ofers multiple channels for community support, such as GitHub discussions [ 17 ] and Discord channels [ 18 ].

As a result, we chose the EDC solution due to its strong alignment with IDSA RAM 4.0 and DSP, as well as its ease of extensibility. Furthermore, it uses the Open Digital Rights Language (ODRL) [ 19 ] for the definition of the data access and usage policies, facilitating future interoperability at the policy level [ 20 ] and supporting future distributed identity management with verifiable credentials.

3. Identity Provider

One of the focuses of the Health Data Space project is exploring and prototyping methods to provide participants with identity information. This aspect has significant implications for the security of the data space, such as ensuring that only authorized users can access the data space ecosystem. This consideration makes the choice of identity provider an essential factor in technical decisions.

To ensure a shared understanding in this decision-making process, we outlined the various available Identity and Access Management (IAM) solutions, examining their implications and their respective advantages and disadvantages.

3.1. Decentralized Identity and Access Management Solutions

Decentralized Web Nodes (DWN) [21] is a DRAFT 2 specification under development within the Secure Data Storage Working Group of the Decentralized Identity Foundation (DIF). The EDC Identity Hub [ 22 ] implemented an early version of this protocol, but that implementation has been deprecated since EDC version 0.5.0 [ 23 ]. Additionally, DWN focuses on generic credential storage rather than permission-based access.

Decentralized Claims Protocol (DCP) [ 24 ] integrates a complete verifiable credentials flow into machine-to-machine communication, facilitating the use of verifiable credentials as a distributed identity management tool for connector communication. However, at the time of the project, the existing EDC implementation of the protocol lacked support for the issuance component [ 25 ] of the verifiable credentials flow [ 26 ]. iShare Trust Framework [ 27 ] provides an identity management solution. However, it does not yet support verifiable credentials and uses a modified OAuth 2.0 flow [ 28 ]. Additionally, the iShare Trust Framework identifies diferent processes and components to build trust compared to IDSA RAM 4.0.

3.2. Central Identity Provider (IdP) Solutions

OAuth using Keycloak (or other IdP that supports Private Key JWT) is a simple solution that utilizes widely recognized technologies. Keycloak can be configured as an external Identity Provider (IdP) and supported by the EDC Connector [ 29 ]. However, active development of this solution has halted within the EDC community. The data space participants also lack direct control over the shared information since it is managed centrally.

OAuth DAPS is listed here for completeness, as only a few implementations have been done, and none fit the Health Data Space. An OAuth2-DAPS extension has been developed for EDC: Omejdn DAPS by Fraunhofer, which no longer receives updates [ 30 ]. Sovity has another implementation, but is tailored for Sovity’s business logic[ 31 ]. To use Sovity’s implementation, the data space participants need to have a “DAT Mapper”, a custom protocol mapper implemented by Sovity, configured and assigned to them; this is not the use case for the Health Data Space.

3.3. OAuth using Keycloak

OAuth using Keycloak, the most supported toolset by EDC solutions and built on widely accepted technologies [ 32 ], was selected for implementing the Health Data Space. To enable the configuration, it is essential to utilize the appropriate EDC extensions, specifically the OAuth 2 Service [ 29 ] and its associated configurations. We did not choose a distributed solution because no toolset could support the entire flow of verifiable credentials at the time of the project. 2A DRAFT specification indicates that the specification is a work in progress and is subject to refinement and modification.

4. Clearing house

During the implementation of the Health Data Space, a specific requirement emerged from the Flemish Department of Care: the health authority needs to have transparency of all transactions occurring within the data space. Furthermore, the authority needs to possess the ability to approve or disapprove contract negotiations and transfer processes. This aligns with the role of a Health Data Access Body (HDAB) as defined in the EHDS regulation [ 33 ]. HDABs are responsible for authorizing and issuing data permits to access electronic health data for secondary use, such as research, policy-making, and other purposes. This requirement is also consistent with the definition of a clearing house in IDSA RAM 4.0 [ 7 ]: the clearing house acts as an intermediary, providing essential services such as clearing, monitoring and settlement for all financial and data exchange transactions. These services are performed at various stages of the data sharing process. Clearing takes place prior to sharing data, and involves verifying usage contracts specified by means of policies. Monitoring is executed during the actual data exchange, and comprises logging transaction metadata originating from both data provider and consumer, which is useful for auditing purposes and resolving possible conflicts. Settlement happens after the sharing of data, and includes administrative tasks like billing, invoicing and resolving possible conflicts [ 34 ].

While the responsibilities of a clearing house in IDSA RAM 4.0 are quite well-defined, their actual implementation leaves room for debate. As an example, the clearing house interfaces with existing data space services such as the identity provider and policy enforcement points (PEP) [ 35 ]. However, it can also ofer services like policy enforcement, enabling data providers to minimize costs by outsourcing policy enforcement [ 34 ]. The uncertainty and flexibility in how a clearing house should be implemented may contribute to the lack of ready-to-use clearing house implementations for data spaces in the market, as stated in [ 6 ]. Therefore, a customized clearing house implementation was introduced in the Health Data Space project, as shown in Figure 2 below.

This extension records events related to contract negotiation and actual data transfers occurring within the EDC connectors of both the data provider and consumer, hereby ofering monitoring functionality that can serve as the basis for settlement. The EDC connector is designed as a state machine, where transactions (both negotiations and transfers) go through a number of well-defined states (e.g., ‘INITIATED’, ‘STARTED’, ...) so these can be logged.

Additionally, the extension allows to temporarily halt transactions at decision-making moments, and delegate them to a specialized user interface (UI) component, if specified in the usage contract. While data sharing in data spaces currently mostly focuses on sending data from one participant to another, more complex scenarios are possible, but they are all built on peer-to-peer contracts between two participants [36]. Within the Health Data Space project, the contract triggering external decision-making includes an ODRL [ 19 ] ‘obtainConsent’ Action, with the clearing house acting as the consenting party. One could also envision contracts between the participants and the clearing house; however, this was not considered for the project. The previously mentioned UI component includes buttons as shown in Figure 3 that facilitate decision making regarding the transaction and subsequently invoke the connector extension’s callback function to either advance the transaction to the next state or terminate it, as depicted in Figure 4.

The UI component is identified as the Clearing House in the Health Data Space project, as it provides monitoring and manual clearing capabilities. In a real-world scenario, this clearing might be more complex and could, for example, involve the Belgian Health Data Agency (HDA) or another HDAB checking whether the data sharing complies with regulations. As such, this implementation primarily served to demonstrate that external decision-making, stretching over an indeterminate duration, is feasible.

5. Semantic Interoperability and Vocabulary Hub

Semantic interoperability is a research area that significantly impacts the implementation of data spaces [ 37 ]. Research work has been done in that domain; for example, the Information Model of the International Data Spaces (IDS-IM) [ 38 ] is the central integration enabler for semantic interoperability in any IDS ecosystem [ 39 ], which defines the fundamental concepts that describe actors in a data space, allowing the data space ecosystem to speak in one language. Data models consisting of ontologies and schemas are key perspectives that can enhance interoperability.

Currently, the only recognized vocabulary service within the Data Spaces Support Centre (DSSC) toolbox [ 40 ] that features data models is the FIWARE Smart Data Models [ 41, 42 ]. This model suite includes a Smart Health perspective, which aligns with the Fast Healthcare Interoperability Resources (FHIR)3 model. FHIR also has its namespace for the RDF (Resource Description Framework) format [ 45 ]. 3Fast Healthcare Interoperability Resources (FHIR) [ 43, 44 ] is a healthcare data standard with an application programming interface (API) for representing and exchanging electronic health records (EHR). However, certain limitations are associated with using FHIR in RDF within the Health Data Space. Notably, no readily available data plane supports FHIR implementations, meaning there is no direct method to integrate an FHIR server or FHIR client to publish and consume FHIR data through a connector.

The Flemish Smart Data Space (VSDS) [ 46, 47 ] has a data plane implementation [ 48 ] for linking a Linked Data Event Stream (LDES) [ 49 ] server [ 50 ] to the EDC connector, complemented by the tool known as Linked Data Interactions [ 51 ], which facilitates the mapping of data from non-RDF to RDF formats. In addition, various resources have been onboarded to LDES as listed in the LDES Registry [ 52 ] and can be shared in the VSDS. Therefore, in developing the Health Data Space, we investigated the application of LDES to publish health data in RDF format. We experimented with converting the data from its original format into linked data models in RDF format and subsequently into the LDES using tools from VSDS. This transformation facilitates data consumption through data space connectors with existing VSDS blocks. However, as stated in [ 6 ], converting health data to the LDES format is challenging, especially in identifying the proper data model in the medical care domain. Additionally, using VSDS building blocks requires the installation of the LDES client, which remains an additional barrier for data providers.

5.1. Vocabulary Hub

The Vocabulary Hub serves as a management platform for data schemas within a data space, ofering schema validation and semantic annotations for various data elements included in the data product4. TNO’s implementations, the Semantic Treehouse [ 54 ] and the IDS Vocabulary Provider [ 55 ], are two vocabulary services currently available in the market, each providing a vocabulary hub service at diferent levels. However, neither service yet supports machine-to-machine integration for communicating 4Data product is a term for data space defined by DSSC Blueprint v2.0 [ 53 ]. A data product typically consists of the resource, which can be data and/or data service, the description of the resource, its allowed purposes of use, quality, format, frequency, duration, and other requirements the data product fulfills, access and control rights (e.g., attribution, Intellectual Property Rights, liabilities, geographical limitations, usability for training LLMs), delivery options (e.g., APIs, SMTP, web interface, mapping tools), information about data provenance and lineage, pricing and billing information, other information (e.g., ethical considerations), and metadata describing all these above. with the connector.

As previously mentioned, a one-size-fits-all data model does not exist in the medical field. The standardization of electronic health records is too complex to be addressed within this project’s scope. As a result, a vocabulary hub for the Health Data Space has not been created. We expect this to happen with future projects with more health-domain use cases in data spaces.

6. Metadata Broker and Data Discovery

The Metadata Broker acts as an intermediary between data providers and data consumers and provides an interface to match data providers with data consumers according to their specific requirements [ 35 ].

Several broker products in the market provide diferent methods for harvesting and collecting metadata. Each product has unique features and approaches to manage metadata efectively. Amundsen, Atlas, DataHub, Marquez, OpenDataDiscovery, and OpenMetadata are the six popular open-source data catalogs [ 56 ]. Each available product comes with its advantages and disadvantages. All of these products fulfill the essential functions required by a Metadata Broker: the ability to expose selected metadata to designated external parties.

We chose to use Datahub in the implementation of Health Data Space, as imec had developed an EDC extension: DataHub emitter extension. This extension enables the following process: when a data product is available in the connector, the extension will emit [57] the metadata of that data product to DataHub as shown in Figure 5. Once the procedure is completed, the metadata is available on the DataHub portal as shown in Figure 6.

6.1. Data Discovery

Populating the catalog into DataHub is the beginning of improving data discoverability; several challenges remain in metadata discovery, particularly regarding machine-to-machine data discovery, including: • The metadata populated by the EDC lacks a precise specification, and the fields are not standardized; this inconsistency makes it dificult for web services to interoperate or harvest the metadata efectively. For example, within the Health Data Space, integration with the Metadata Flanders portal [ 58 ] has been explored. This portal automatically harvests data against Data Catalog Vocabulary (DCAT) standards, but there are mismatches between the fields in the EDC catalog and those expected by the Metadata Flanders DCAT. Additionally, the EDC metadata does not provide enough information to be efectively valuable in the portal. • The current metadata provided by the EDC connector does not include annotations or validations regarding the sharing or shared data itself, making it challenging to understand the schema or content of the data. The lack of a vocabulary hub service and a standardized method for expressing schema across EHR also impacts the current challenge. • The Linked Data community advocates for using RDF and SHACL [ 59 ] to validate and discover RDF data; this has also been investigated in the project. It is important to note that not all data are available in RDF format. In addition, the process of mapping to specific RDF models can be pretty complex. There is also a significant reluctance among data owners, particularly in the healthcare sector, to participate in this mapping efort [ 6 ].

7. Conclusion

The Flemish Health Data Space project [ 6 ] conducted a technical review of the data space ecosystem as of 2024. We examined a wide range of available technical resources and components, particularly focusing on EDC connectors. We successfully built a minimum viable data space that has been deployed on the customer side. However, several challenges remain in the implementation of a data space. • Semantic interoperability has been partially achieved at the metadata level but not at the data level.

Machine discovery poses extreme challenges due to the lack of unified standards and insuficient supporting tools. Without secured, accessible toolsets, data owners may lack confidence in transferring and processing their data, especially in the health sector, where data confidentiality is paramount. • The implementation of a clearing house can vary significantly according to requirements, as no definitive answer is provided by RAM 4.0 [ 35 ] and RAM 5.0 [ 60 ]. • Distributed identity utilizes verifiable credentials for machine-to-machine communication, which is still in the theoretical specification stage, with tools actively being developed and protocols being fine-tuned.

The challenges mentioned are progressing across various communities and projects. For example, RAM 5.0 [ 60 ] is evolving within the IDSA working group [ 61 ], while the European Electronic Health Record exchange Format (EHRxF) [ 62 ] is improving medical record models. Additionally, we are excited to see advancements in the data space field. Numerous active developments are underway to realize the Dataspace Protocol, DCAT, and other specifications. Data spaces have gained traction across various domains, with the Flemish Health Data Space serving as a showcase of this advancement.

Declaration on Generative AI

During the preparation of this work, the authors used GitHub Copilot in order to: Grammar and spelling check, Paraphrase and reword. After using these tools/services, the authors reviewed and edited the content as needed and take full responsibility for the publication’s content. [36] International Data Spaces Association. IDSA Rulebook: Functional Requirements. 2024. url: https: / / docs . internationaldataspaces . org / ids - knowledgebase / idsa - rulebook / idsa - rulebook / 3 _ functional_requirements.

References

[1] European Commission . A European strategy for data. Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of the Regions . COM ( 2020 ) 66 final, 2020 - 02 -19. url: https://eur-lex.europa.eu/legalcontent/EN/TXT/?uri=CELEX% 3A52020DC0066 .

[2] Graca Carvalho and Emre Kazim . “ Themes in data strategy: thematic analysis of 'A European Strategy for Data' (EC)” . In: AI and Ethics 2 ( Feb . 2022 ), pp. 1 - 11 . doi: 10 .1007/s43681-021-00102-y.

[3] Teodora Groza and Beatriz Arcila . “ The New Law of the European Data Markets: Demystifying the European Data Strategy” . In: Global Jurist 24 ( June 2024 ), pp. 321 - 364 . doi: 10 .1515/gj-2024-0045.

[4] Simon Scerri et al. “ Common European Data Spaces: Challenges and Opportunities” . In: Sept . 2022 , pp. 337 - 357 . isbn: 978 -3- 030 -98635-3. doi: 10 .1007/978-3- 030 -98636-0_ 16 .

[5] Jane Arroyo , Hien Vu, and Timothy Yu-Cheong Yeung . “ The European Health Data Space: Will it be emergency-ready?” In: Health and Technology 14.2 ( 2025 ), p. 100977 . issn: 2211 - 8837 . doi: https://doi.org/10.1016/j.hlpt. 2025 . 100977 . url: https://www.sciencedirect.com/science/article/ pii/S221188372500005X.

[6] Departement Zorg , Center for IT and IP Law - KU Leuven - (CiTiP), and imec . Eindrapport Vlaamse Health Data Space Project. In Dutch . 2025 . url: https://publicaties.vlaanderen.be/viewifle/72591.

[7] Sebastian Steinbuss et al. “ IDS Reference Architecture Model 4 (IDS-RAM 4)” . In: (Apr. 2022 ).

[8] International Data Spaces Association. IDS Reference Architecture Model Version 4 - System Layer . 2025 . url: https://docs.internationaldataspaces.org/ids-knowledgebase/ ids-ram-4/layers-of-thereference-architecture-model/3-layers-of-the-reference-architecture-model/3_5_0_system_ layer.

[9] Anna Gieß et al. “ What Does it Take to Connect? Unveiling Characteristics of Data Space Connectors” . In: Jan . 2024 . doi: 10 .24251/HICSS. 2024 . 511 .

[10] International Data Spaces Association . The Data Spaces Radar . 2024 . url: https : / / internationaldataspaces . org / wp - content / uploads / dlm _ uploads / The - Data - Spaces - Radar - Version-4.pdf.

[11] International Data Spaces Association. Dataspace Protocol . 2024 . url: https : / / docs . internationaldataspaces.org/ids-knowledgebase/dataspace-protocol.

[12] Mark Ryan , Paula Gürtler, and Artur Bogucki. “Will the real data sovereign please stand up? An EU policy response to sovereignty in data spaces” . In: International Journal of Law and Information Technology 32 ( July 2024 ). doi: 10 .1093/ijlit/eaae006.

[13] EDC Contributors. EDC Connector Welcome Page . 2025 . url: https://github.com/eclipse- edc/ .github/blob/27f33847ecb05c50a1d9c63ba949aef619da24cb/profile/README.md?plain=1# L10 .

[14] Tobias Dam et al. “ A Survey of Dataspace Connector Implementations” . In: Proceedings of the 2nd Italian Conference on Big Data and Data Science (ITADATA 2023 ), September 11-13 , 2023 , Naples, Italy. Vol. 3606 . CEUR Workshop Proceedings. 2023 . url: https : / / ceur - ws . org / Vol - 3606 /paper41.pdf.

[15] Jonah Windolph , Michael Pahl , and Stefen Kaup. “ Gaia-X as an Enabler to Shape Interconnected Logistics in Europe” . In: May 2024 . doi: 10 .35090/gatech/11091.

[16] Bennet Gerlach et al. “ Gaia-X-Med : Experiences with Building Dataspaces for Medical Applications” . In: Oct. 2024 . doi: 10 .20944/preprints202410. 1403 . v1 .

[17] EDC Contributors. EDC Connector Github Discussions . 2025 . url: https://github.com/orgs/eclipseedc/discussions.

[18] EDC Contributors. Eclipse Dataspace Components Discord . 2025 . url: https://discord.com/invite/ n4sD9qtjMQ.

[19] Renato Iannella and Serena Villata . ODRL Model . 2018 . url: https://www.w3.org/TR/odrl-model/.

[20] [21] Harshvardhan Pandit and Beatriz Esteves . “ Enhancing Data Use Ontology (DUO) for health-data sharing by extending it with ODRL and DPV” . In: Semantic Web 15 (Feb . 2024 ), pp. 1 - 26 . doi: 10 .3233/SW-243583.

Daniel Buchner and Tobias Looker . Decentralized Web Node. Accessed: 2025-02-27 . 2025 . url: https://identity.foundation/decentralized-web-node/spec/.

[22] EDC Contributors . 2023 - 09 -06 - identity-trust. 2023 . url: https://github.com/eclipse-edc/docs/tree/ main/developer/decision-records/2023-09-06 -identity-trust#identity-hub.

[23] EDC Contributors. EDC Identity Trust . Accessed: 2025-02-27 . 2023 . url: https://github.com/eclipseedc/docs/tree/main/developer/decision-records/2023-09-06 - identity-trust.

[24] EDC Contributors. Decentralized Claims Protocol . Accessed: 2025-02-27 . 2025 . url: https://github. com /eclipse-dataspace-dcp/decentralized-claims-protocol.

[25] Eclipse Dataspace Connector . Minimum Viable Dataspace Demo . 2024 . url: https : / / github . com/eclipse-edc/MinimumViableDataspace/blob/138adf8c0764c80f65537a7a956367ebf0f90c5/ README.md#93 -no-issuance-yet.

[26] Manu Sporny et al. Verifiable Credentials Data Model v2.0 . 2025 . url: https://www.w3.org/TR/vcdata-model- 2 .0/.

[27] iShare. iShare Trust Framework for Data Rights . 2025 . url: https://ishare.eu/.

[28] iShare. RFC040: Verifiable Credentials Support . Accessed: 2025-02-27 . 2024 . url: https://gitlab.com/ ishare-foundation/cab/rfc/-/issues/5.

[29] EDC Contributors . EDC-OAuth 2 Service . Accessed: 2025 -02- 27 . 2025 . url: https://github.com/ eclipse-edc/Connector/tree/main/extensions/common/iam/oauth2/oauth2-service.

[30] epanagou-ubitech. Omejdn DAPS: Contract negotiation fails when using the EDC oauth2-daps extension . Accessed: 2025-02-27 . 2023 . url: https://github.com/sovity/edc-ce/issues/654.

[31] Sovity . Sovity DAPS . 2025 . url: https://github.com/sovity/sovity-daps.

[32] Yoav Nahshon et al. “ Semantic Orchestration and Exploitation of Material Data: A Dataspace Solution Demonstrated on Steel and Copper Applications” . In: Advanced Engineering Materials (Dec. 2024 ). doi: 10 .1002/adem.202401448.

[33] The European Parliament and the Council of the European Union . Regulation (EU) 2025/327 of the European Parliament and of the Council of 11 February 2025 on the European Health Data Space and amending Directive 2011 /24/EU and Regulation (EU) 2024 /2847. 2025 . url: https://eurlex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_ 202500327 .

[34] International Data Spaces Association . Specification: IDS Clearing House . 2020 . url: https : / / internationaldataspaces . org / wp - content / uploads / dlm _ uploads / IDSA - White - Paper - Specification -IDS-Clearing- House-. pdf.

[35] International Data Spaces Association. IDS Reference Architecture Model Version 4 . Accessed: 2025 -02- 27 . 2023 . url: https://docs.internationaldataspaces.org/ids-knowledgebase/ids-ram- 4 .

[37] Jawad Kazmi et al. “ Dataspace for Research - Ideas, use cases and technology” . In: Sept . 2024 .

[38] Christian Mader et al. International Data Spaces Information Model . 2025 . url: https://internationaldata-spaces-association.github.io/InformationModel/docs/index.html.

[39] Thomas Berlage et al. “ Medical Data Spaces in Healthcare Data Ecosystems” . In: Designing Data Spaces : The Ecosystem Approach to Competitive Advantage . Ed. by Boris Otto, Michael ten Hompel, and Stefan Wrobel . Cham: Springer International Publishing, 2022 , pp. 291 - 311 . isbn: 978 -3- 030 -93975-5. doi: 10 .1007/978-3- 030 -93975-5_ 18 .

[40] Data Space Support Center . DSSC Toolbox. Accessed: 2025-02-27 . 2025 . url: https://dssc.eu/page/ toolbox.

[41] FIWARE. Smart Data Models. Accessed: 2025-02-27 . 2025 . url: https://github.com/smart-datamodels/data-models.

[42] Ulrich Ahle and Juan Hierro . “ FIWARE for Data Spaces” . In: July 2022 , pp. 395 - 417 . isbn: 978 -3- 030 -93974-8. doi: 10 .1007/978-3- 030 -93975-5_ 24 .

[43] [44] HL7 . HL7 FHIR v5.0.0 . 2025 . url: https://www.hl7.org/fhir/.

In: JMIR Medical Informatics 9 ( Aug . 2021 ), e32869 . doi: 10 .2196/32869.

[45] Eric Prud' hommeaux et al. “ Development of a FHIR RDF Data Transformation and Validation Framework and Its Evaluation” . In: Journal of Biomedical Informatics 117 ( Mar . 2021 ), p. 103755 . doi: 10 .1016/j.jbi. 2021 . 103755 .

[46] Vlaamse Overheid . Flemish Smart Data Space . in Dutch, accessed: 2025 -02- 27 . 2025 . url: https: //www.vlaanderen.be/vlaamse-smart -data-space-portaal.

[47] Dwight Lancker et al. “ Semantic and Technically Interoperable Data Exchange in the Flanders Smart Data Space” . In: Nov . 2024 , pp. 289 - 303 . isbn: 978 -3- 031 -77846-9. doi: 10 .1007/978-3- 031 - 77847-6_ 16 .

[48] Vlaamse Overheid. VSDS Dataspace Connector . Accessed: 2025-02-27 . 2025 . url: https://github. com/Informatievlaanderen/VSDS-Dataspace-Connector.

[49] Dwight Lancker et al. “ Publishing Base Registries as Linked Data Event Streams” . In: May 2021 , pp. 28 - 36 . isbn: 978 -3- 030 -74295-9. doi: 10 .1007/978-3- 030 -74296- 6 _ 3 .

[50] Vlaamse Overheid. VSDS LDES Server . Accessed: 2025 -02- 27 . 2025 . url: https://github.com/ Informatievlaanderen/VSDS-LDESServer4J.

[51] Vlaamse Overheid . Linked Data Interactions. Accessed: 2025-02-27 . 2025 . url: https://github.com/ Informatievlaanderen/VSDS- Linked- Data-Interactions.

[52] imec . LDES Registry . 2025 . url: https://imec-int.github.io/ldes-registry/dashboard.html.

[53] Data Spaces Support Center . Data Product - Blueprint v1.5 . 2025 . url: https://dssc.eu/space/bv15e/ 766065053/Data+Product.

[54] TNO. Semantic Treehouse . 2025 . url: https://www.semantic-treehouse.nl.

[55] International Data Spaces Association. IDS-VocabularyProvider . 2025 . url: https://github.com/ International-Data-Spaces-Association/IDS-VocabularyProvider.

[56] Atlan . Top 6 Open Source Data Catalog Tools to Consider in 2025 . 2025 . url: https://atlan.com/opensource -data-catalog-tools/?ref=/openmetadata-vs-datahub/.

DataHub Project Authors . Java Emitter . 2025 . url: https://datahubproject.io/docs/metadataintegration/java/as-a-library/.

[58] Vlaamse Overheid . Metadata Vlaanderen . In Dutch. 2025 . url: https://metadata.vlaanderen.be/ srv/dut/catalog.search#/home.

[59] Holger Knublauch and Dimitris Kontokostas . Shapes Constraint Language (SHACL) . 2017 . url: https://www.w3.org/TR/shacl/.

[60] International Data Spaces Association . IDS Reference Architecture Model Version 5 . 2025 . url: https://docs.internationaldataspaces.org/ids-ram-5 - working-draft.

[61] International Data Spaces Association. IDSA Working Groups . Accessed: 2025-4-11 . 2025 . url: https://internationaldataspaces.org/we/working-groups/.

[62] European Electronic Health Record Exchange Format. European Electronic Health Record Exchange Format (EHRxF) . Accessed: 2025-4-11 . 2025 . url: https://ehr-exchange-format.eu/.