Table 1
Median, interquartile range (IQR) and percentage distribution of self-assessed expertise, based on responses collected using a five-point rating scale.
| TOPIC (n = 40) | MEDIAN (IQR) | SELF-ASSESSED EXPERTISE, n (%) |
|---|---|---|
| FAIR principles | 3 (2) | 1: 8 (20%); 2: 5 (12.5%); 3: 12 (30%); 4: 7 (17.5%); 5: 8 (20%) |
| Semantic web | 2 (2) | 1: 18 (45%); 2: 9 (22.5%) 3: 5 (12.5%); 4: 3 (7.5%); 5: 5 (12.5%) |
| Ontologies | 2 (1.5) | 1: 10 (25%); 2: 13 (32.5%); 3: 7 (17.5%); 4: 6 (15%); 5: 4 (10%) |
| Knowledge/data | 3 (2) | 1: 11 (27.5%); 2: 8 (20%); 3: 13 (32.5%); 4: 8 (20%); 5: 0 (0%) |
| (Meta)Data Standards | 3 (2.25) | 1: 12 (30.0%); 2: 7 (17.5%); 3: 11 (27.5%); 4: 5 (12.5%); 5: 5 (12.5%) |
| Software/scripting | 3 (3) | 1: 11 (27.5%); 2: 6 (15.0%); 3: 9 (22.5%); 4: 8 (20.0%); 5: 6 (15.0%) |
| HCP software | 1 (2) | 1: 23 (57.5%); 2: 6 (15.0%); 3: 9 (22.5%); 4: 1 (2.5%); 5: 1 (2.5%) |
[i] Significance is measured on a Likert scale ranging from ‘1 – Low expertise on topic’ to ‘5 – Expert on topic’.
Table 2
Summarisation of the main solutions proposed by the hackathon participants.
| CHALLENGE | SUMMARY OF KEY FINDINGS | RELATED REUSED TECHNOLOGIES |
|---|---|---|
| Challenge #1: What components are needed for secure querying of RD data? | A hybrid querying architecture was proposed consisting of a query trigger, central query processor, and secure data querying interfaces at data-holding institutions. Queries are authorised based on machine-readable policies, executed locally against harmonised datasets, and return only aggregated results, ensuring privacy by keeping sensitive patient data within institutional boundaries. | ODRL (Iannella, 2004) for machine-readable query policies; FAIR Data Point (Bonino da Silva Santos et al., 2025) for query policies description; GA4GH Beacon Protocol (Rambla et al., 2022) for query interface standardisation; FAIR Data Station (Bonino da Silva Santos, Burger and Kaliyaperumal, 2021) for query execution; Dremio (Dremio, 2025) and Ontop (Bagosi et al., 2014) for querying virtualisation and translation. |
| Challenge #2: How can heterogeneous HCP data be harmonised using semantic models? | Heterogeneous HCP data can be harmonised through a semantic data model, supported by a transformation pipeline that ingests raw exports, performs semantic enrichment and code mapping to Orphanet identifiers, and converts the data into a standardised representation. | CARE-SM (Alarcón-Moreno and Wilkinson, 2024), SIO (Dumontier et al., 2014) and Orphanet codes (Orphanet, 2025) for semantic enrichment and interoperability; RML (Dimou et al., 2014) or Ontop (Bagosi et al., 2014) for syntactic harmonisation and mapping; DuckDB (Raasveldt and Mühleisen, 2019), SQL and Python functions for data ingestion. |
| Challenge #3: What technologies enable machine-actionable discovery of data services? | Machine-actionable discovery of data services is enhanced with domain-specific resource descriptions and formalised usage conditions so that data services, access rules, and query capabilities can be discovered and interpreted automatically by both humans and software agents. | FAIR Data Point (Bonino da Silva Santos et al., 2025) for resource description; DCAT (Albertoni et al., 2024); and the EJP RD Metadata Model (EJP RD, 2025b) for metadata standardisation; NCIT (de Coronado, Remennik, and Elkin, 2023) and Orphanet codes (Orphanet, 2025) for machine-readable domain description in rare diseases. |
[i] EJP RD: European Joint Programme on Rare Diseases; NCIT: National Cancer Institute Thesaurus; ODRL: Open Digital Rights Language; RML: RDF Mapping Language; SIO: Semanticscience Integrated Ontology.
Figure 1
Proposed architecture for the network of resources containing four main components: the query trigger, the query processor, the FAIR Data Station, and the FAIR Data Point. The query request and the HCP harmonised dataset are also represented in the figure. The harmonised dataset and FAIR Data Point components are further detailed in challenges #2 and #3, respectively. The numbers on each connection show the order in which the requests are executed. Connections with arrows on both sides indicate that a response to the request is required before the flow can continue. Dotted lines show protected data access, while dashed lines show data exchange.
Figure 2
Example of ODRL model to be used in the proposed architecture, designed for the patient cohort use case.
Figure 3
A simplified excerpt of CARE-SM. Elements in light blue rounded rectangles represent classes of CARE-SM, with SIO’s superclasses described in <<italic>>. The specific ontological type for each node is shown in a yellow box, and examples of data instances are shown in green boxes with dashed borders.
Figure 4
Illustration of the proposed pipeline for data harmonisation in Challenge #2.
Table 3
Examples of ontology terms to be used to describe rare disease resources in the FDP.
| LABEL | ONTOLOGY ID |
|---|---|
| Patient outcomes registry | NCIT_C119669 |
| Patient identifier | NCIT_C164337 |
| Diagnosis | NCIT_C154625 |
| Age | NCIT_C25150 |
| Genotype | NCIT_C16631 |
| Healthcare provider | NCIT_C16666 |
| Diseases | Orpha_98896 (example for ‘Duchenne muscular dystrophy’) |
[i] FDP: FAIR Data Point.
Figure 5
An example of a data service description as displayed in the FAIR Data Point (FDP) user interface. The ‘Ontological Description’ and ‘Keywords’ fields use standard terms to define the topic of the data being served, while the ‘Endpoint URL’ provides the direct machine-readable address to access the service. Finally, the ‘Endpoint Description’ offers human-readable instructions, such as a link to external documentation or a direct explanation of how to use the service.